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ABSTRACT 


If a single operating system can support multitudes of different programming 
languages and data structures, a database system can support a variety of data models and 
data languages. In this thesis, a Kernel Database System (KDS) supporting classical data 
models and data languages (i.e., hierarchical, network, relational, and functional) is used 
to support a demonstration object-oriented data model and data language. 

This thesis extends previous research by accommodating an object-oriented-data- 
model-and-language interface in the KDS. Consequently, the research shows that it is 
feasible to use the KDS to support modem data models and languages as well as classical 
ones. This thesis details the KDS design. Insert operation, and Display function. This thesis 
also details how to implement modifications to the Test-Interface so that the KDS can 
support the object-oriented database. 

This thesis proves complex data stmctures in an object-oriented data model can be 
realized using an attribute-based data model which is the kernel data model of the KDS. 
Second, it details how the KDS is designed showing why no changes needed to be made to 
the KDS to implement the object-oriented toy database. Third, it argues the advantages of 
using a KDS in the database-system design. The KDS design produces savings in costs 
from compatability, reduced training, expandability, and software reuse. 
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L INTRODUCTION 


Users view and access their databases using specific pairs of corresponding data 
models and data languages of database systems. Database computers and systems continue 
to associate with their specific pairs of data models and data languages. Because mono¬ 
model and mono-lingual database systems have persisted over the last three decades, many 
organizations support multiple database systems. These organizations are compelled to 
support multiple database systems in order to maintain diverse t5^es of applications. The 
redundancy of data, personnel, maintenance, documentation, and hardware points to the 
following need: to move multiple database systems (each of which has a different pair of 
data model and data language) to a single database system that can support a multitude of 
models and languages. 


A. TOWARDS A KERNEL DATABASE SYSTEM DESIGN 

If a single operating system can support multitudes of different programming 
languages and data structures, can a database system support a variety of data models and 
data languages? In this thesis, a kernel database system is proposed which supports, in 
addition to classical data models and data languages such as the hierarchical, network, 
relational, and functional, the emerging object-oriented data model and data language. 


B. EXTENDING AN EXISTING KERNEL DATABASE SYSTEM 

The Multi-model and Multi-lingual Database Management System (MODEMS), at 
the Naval Postgraduate School’s Laboratory for Database Systems Research has 
successfully demonstrated that classical data models and their associated data languages 

can be supported on a single database system. Using MODEMS as the experimental Kernel 
Database System (KDS), research teams have constructed and implemented model-and- 
language interfaces that support the classical data models and languages (Hierarchical and 
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DLI, Network and CODASYL-DML, Relational and SQL) and that supports one 
Artificial-Intelligence based model and language (i.e., Functional and DAPLEX). 

This thesis extends the previous research by accommodating an object-oriented- 
data- model-and-language interface in the KDS. Consequently, the research shows the 
feasibility of using the KDS to support modern data models and languages as well as 
classical ones. This thesis details the issues and solutions of creating an object-oriented 
database in the kernel format in the KDS. 

Creating an object-oriented database in the KDS advances the theory that complex 
data structures found in the object-oriented data model can be realized as a kernel database 
in a single database system. It is therefore unnecessary to build an entirely new object- 
oriented database system to support an object-oriented database. 

C. THE OBJECTIVES OF THE THESIS 

This thesis has three objectives: First, it shows that complex data structures in an 
object-oriented data model can be realized using an attribute-based data model which is the 
kernel data model of the KDS. Second, it discovers relevant issues when using the KDS to 
support an object-oriented database. Third, it argues the advantages of using a KDS in the 
database-system design. As a by-product of these three objectives, this thesis also provides 

appendices on the structure, function, and operation of the MODEMS. 


D. THESIS ORGANIZATION 

In Chapter II, we present the modern object-oriented database model and introduce 
the features, notions, and constructs of the object-oriented database. In Chapter 11, the 
design test of an object-oriented database in terms of its object-oriented specifications is 
also introduced. In Chapter HI, we explain the significance of being able to use the KDS to 

support an object-oriented database by providing an overview of the MODEMS, i.e., its 
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organization, operation, and design. In Chapter III, we also introduce the attribute-based 
data model and Kernel Database stractiire. In Chapter IV, we detail the design of the 
Kernel Database System and processes. In Chapter V we show the Insert operation. We 
also show how the KDS maps an object-oriented database to an equivalent attribute-based 
database. In Chapter V, we analyze our experience on using the object-oriented data model/ 

language interface in MODEMS and the need for a Mass_Load() utility. In Chapter VI, is a 
discussion of the Kernel Formatting System (KFS) added to our research to assist other 
teams and their progress. In Chapter VII, we summarize our accomplishments and point 
out some limitations of this research. Using an attribute-based data model, the Kernel 
Database System can realize complex data structures in the object-oriented data model. 
However, we suggest some future research using the attribute-based data model in Chapter 
VII. 
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11. SUPPORTING THE OBJECT-ORIENTED DATABASE 


Prior to this research, it has not been clear whether or not the Kernel Database 
System (KDS), designed to support classical databases, can support the complex object- 
oriented database. Specifically, can the KDS support an object-oriented database which 
includes the object-oriented paradigms of inheritance, covering, encapsulation, and 
polymorphism? Object-oriented constructs are complex. Object-oriented paradigms are 
fundamentally different from paradigms of classical databases. The real issue involves 
whether or not a kernel database with only attribute-value pairs can be used to represent 
complex constructs. Can the KDS support complex constructs like those fundamental to 
object-oriented paradigms? 


A. CLASSICAL AND OBJECT-ORIENTED DATABASE MODELS 

Classical databases are specifically designed to support certain well-defined 
applications. The relational database supports one-to-one relationships between individuals 
and records kept for the individuals, commonly found in record keeping. The hierarchical 
database supports the multiple layers of one-to-many relationships commonly found in 
assemblies, their subassemblies, their sub-subassemblies, and so on. The network database 
supports the many-to-many relationships of supplies and suppliers commonly found 
between inventories and suppliers. The functional database supports the association of 
rules and facts with inferences commonly found in knowledge-base and expert system 
applications [Hsiao, Aug 91, pp 3-4]. 

On the other hand, the object-oriented database does not aim at any particular type 
or kind of applications. It follows an object-oriented paradigm in order to group data as an 
abstraction of some real world entities. To properly model the real-world entities, data 
should be encapsulated as objects of these real-world entities. Each object can first be 
modeled as a separate entity independent of other objects. Each object has it’s own set of 
attributes and operations. Object-oriented constmcts are based on the set theory; the object- 
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oriented operations on set operations. The object-oriented paradigm combines the idea of 
inheritance with the idea of encapsulation to form a coherent whole as a class hierarchy. 
Unlike the classical data constmcts, object-oriented construct stores operations and data 
together [Badgett, 95]. Proponents of object-oriented databases claim by using these ideas, 
they can support variety, spontaneity and dynamism in database designs. This thesis is not 
aimed at validating these ideas, but is aimed at using the KDS to support an object-oriented 
database for the purpose of experimenting with the features of object-oriented constructs. 
The object-oriented database implemented on KDS retains its flexibility, portability, and 
homogeneity. In this way, we can make use of object-oriented concepts and constructs 
without the need of building a new object-oriented database system. 


B. TESTING THE OBJECT ORIENTED DATABASE 

For creating an object-oriented database, an object-oriented data model (OODM) 
and object-oriented data language (OODDL) are developed [Badgett, 95]. After the object- 
oriented database is modeled in OODM and specified in OODDL, the database is compiled 
into an attribute-based database. The INSERT operation in the attribute-based data 
definition language (ABDL) is used to create the attribute-based database in the KDS. This 
thesis documents how the INSERT operation creates in the KDS the attribute-based 
database which is equivalent to the object-oriented database. This thesis also documents 
why there is no modification required in the KDS in order to accomplish the creation. 
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III. THE MULTI-MODEL MULTI-LINGUAL DATABASE SYSTEM 


M^DBS organization has two parts: the multibackend database supercomputer, the 
Multimodel/multilingual database system. The Kernel Database System (KDS), the Kernel 
Data Model (KDM) and the Kernel Data Language (KDL) are a software subset of the total 

M^DBS. To understand the KDS, KDM, and KDL a review of the system organization 
helps to place the kernel into context with the overall system architecture. 


A. THE MULTIBACKEND DATABASE SUPERCOMPUTER 

The multibackend architecture consists of several computers connected in parallel 
by Ethernet. The parallel connection supports distribution of the database across these 
several computers for rapid access during queries. Each backend computer has its on disk 
system controller, meta disk, and stored data disk. Each backend is controlled by a 
backend controller that supervises the execution of user transactions (see Figure 1). 
Because of the multibackend database design, database access time is significantly 
reduced. The response-time ratio for queries is inversely proportional to a given number of 
backend computers. So, as the number of backends increase, the response time decreases. 
If the number of backends increase proportionally with increases in database capacity, there 
will be no change in transaction response-time. Therefore, the multibackend design can 
support dynamic growth of the database, and can support this dynamic growth without 
noticeable changes in response time. 
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Figure 1: The Multibackend Database Supercomputer 


B. THE MULTIMODEL/MULTILINGUAL DATABASE SYSTEM 

The multibackend database supercomputer is used to support the M DBS software. 
As mentioned earlier, the software is a KDS supporting any data model, and any data 
language chosen by the user. Figure 2 depicts the concept. All data is stored in the KDS as 
attribute-valued pairs using the KDM and KDL associated with the KDS (i.e., ABDM and 
ABDL). To access the data, and to query the data requires a user interface that presents to 
the user the data model and language chosen. The user does not interface with the kernel. 
The user interfaces with the chosen data model and language. The system interfaces with 
the kernel. Figure 3 shows the multimodel/multilingual database system [Hsiao, 91]. The 
four main modules of each user data model/language (UDM/L) interface are the language 
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interface layer (LIL), the kernel mapping system (KMS), the language interface controller 

(LIC)^ and the kernel formatting system (ICFS). These four modules represent the core 
system for each separate user interface. In other words, each UDM/L interface has to have 
its own LIL, KMS, LIC, and KFS which support only the data model and data language 
associated with that UDM/L interface. These modules interact with the KDS through the 
Test Interface (TI) within the KDS. To construct a new UDM/L does not require a redesign 
of the whole database system. The new UDM/L is independent of the other UDM/L’s and 
no changes to the KDS are made provided the new UDM/L follows the design and 
constructs provided by the TI. How to interface with TI is covered in Chapter IV and in the 
User Manual (Appendix A). 


User Data Model/Langauge Kernel Database System 



Figure 2; The Kernel Concept 

The user’s transactions are routed to the KMS by the LIL. The user writes the 
transactions in the associated UDM/L provided by LIL. The KMS is a compiler that 
transforms the UDM/L into a form that can be mapped to the KDS. LIL sends the 

1. In the previous literature, the language interface controller (LIC) is called the kernel controller 
(KC). The research team changed the name of this module to clarify the relationship of the control¬ 
ler to the interface. Kernel controller implies the controller is related to the kernel rather than the 
language interface. 
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transaction to KMS, and KMS interprets the transaction. The KMS first identifies whether 
or not the user is creating a new database or using an existing database. 



JDNM Relational 


DM Object-Oriented 




UDM - User Data Model 
UDL - User Data Language 
LIL - Language Interface Layer 
KMS - Kernel Mapping System 
Lie - Language Interface Controller 
KDS - Kernel Database System 
KDM - Kernel Data Model 
KDL - Kernel Data Language 
KFS - Kernel Formating System 


System Module 
Data Model 



Data Language 


Figure 3: The Multi-Model/Multi-Lingual Database System 











If the user is creating a new database, KMS will transform the UDM-database 
definition to the KDM-database definition. KMS then routes the KDM-database definition 
to the Lie. The LIC, recognizing the KDM-database definition as a new definition, routes 
the KDM-database definition to the KDS. Receiving the KDM-database definition causes 
the KDS to issue appropriate conunands to the multibackend database supercomputer 
controller where a new database is created in the KDM form. After creating the new 
database, the KDS notifies the LIC that a new database has been created in the UDM form. 
Data can now be entered. Subsequently transactions against the database can be made. 

UDL transactions are written within the LIL and processed through the KMS. The 
KMS performs data-language translations by compiling the UDL transactions into 
equivalent KDL transactions. The KMS then routes the compiled KDL transactions to LIC. 
The LIC sends the KDL transaction to KDS for execution. The LIC oversees KDL 
transaction execution. The LIC executes the KDL-transaction through the TI of the KDS. 
Transaction results and/or responses are sent to the LIC which sends them to the KFS. The 
KFS is where the results of a query are reformatted into UDM form. The KFS re-compile 
the information in KDM form to UDM form. Once the transformation is complete, KFS 
routes the transformed information to the LIL where the user sees the information in the 
user’s data model/language form. 

All data in the Multi-model, Multi-Language Database System (M2DBS) is stored 
in the Kernel Database System (KDS) according to the constructs of the Kernel Data Model 
(KDM) and the Kernel Data Language (KDL). Although many database models can be 
used to support a kernel, only the Attribute-Based Data Model (ABDM) supports the 

architecture of the M^DBS and the parallelism associated with the multibackend design. 
The ABDM is the KDM for the M^DBS. The ABDM was chosen as the kernel data model 
because ABDM allows for storage of the meta data and base data separately. ABDM 
introduces equivalence relations which partition the base data into mutually exclusive sets 
called clusters. These clusters are distributed across the backends allowing parallel access 
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to the base data. Coupling ABDM with the ABDL as the KDL facilitates database design. 
The attribute-based model and language support database research with a semantically rich 
and complete language. The ABDM and ABDL also support database research with a 
simple storage and parallel processing architecture. 


C. THE ATTRIBUTE-BASED DATA MODEL 

The ABDM and its associated data language have proven to provide all of the 
required data definition capabilities and manipulation strategies necessary to implement 
Hierarchial, Network, Relational, and Functional data models [Demurjian, 87]. The attri¬ 
bute-based data model is simple in design and concept[Hsiao, 91]. As the name implies, the 
attribute-based data model refers to storing data as a series of attribute-value pairs. 
Attribute-value pairs are the simple building blocks of the kernel database. The attribute- 
value pairs consist of attribute names and corresponding values. An attribute-value pair is 
a member of the Cartesian product of the attribute name and the domain of values of the 
attribute. The pair is formed by using a keyword as the first attribute and the value 
associated with that keyword as the second attribute. The keyword serves to form records. 
The keyword is the key for the attribute and the record is a grouping of attribute-value pairs. 
The second attribute is the record body consisting of a string of characters which represent 
information. The first attribute-value pair must be an identifier of the record type (i.e., file 
name). This pair is declared using the reserved word TEMP. For example: 

(<TEMP, NAME>, <FIRST, Daii>, <LAST, Kellett>) 

(<TEMP, NAME>, <FIRST, Tae-Wok>, <LAST, Kwon>) 

The angle brackets (i.e., <,>) enclose the attribute-value pair. Parenthesis enclose 
the entire record. The example record consists of three attribute-value pairs. TEMP is 
always the keyword of the first attribute-value pair and the value in this pair is always the 
name of a file holding the database. In the example, the name of the file holding these 
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records is NAMES. The attribute name is always the first element of the pair. Attribute 
names are always in uppercase. No two attribute-value pairs can have the same attribute 
name. Keywords must be unique within the record. All the data stored in the database is 
stored in this simple format. Each file represents a table of records. Each record is simply 
a row in a table. The keywords (i.e., attribute) denote the column headings. Each record is 
the value associated with the attribute from one row. Whatever model the user chooses to 
interface with the attribute-based data model, the user’s information is translated into a set 
of records consisting of attribute-valued pairs. 


D. THE ATTRIBUTE-BASED DATA LANGUAGE 

The attribute-based data model provides a complete set of operations to access the 
database. To append records to the database requires the use of the reserved word 
“INSERT’. INSERT is followed by the record to append in the database. For example: 


[INSERT(record)] 

[INSERT(<TEMP, NAME>, <FIRST, Dan>, <LAST, KeUett>)] 

[INSERT(<TEMP, NAME>, <FIRST, Tae-Wok>, <LAST, Kwon>)] 

Using the reserved word “INSERT” causes the system to create the database file 
called NAMES or if there is not a file, the system will create a new one. The records are 
then inserted into the new database or appended to the existing database. 

Access to the database employs the use of predicates. Predicates are constructed by 
using a reserved keyword, a relational operator, and a value. Queries are formed using 
reserved words associated with a predicate. Each query is prefaced with a reserved word 
followed by a predicate. For example: 

[RETRIEVE (predicate)(target list)] 

[RETRIEVE(TEMP = NAME) (LAST, FIRST)] 
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The second example will retrieve all the records in NAMES in the order of LAST, 
and FIRST. There are five queries supported by the attribute-based data language; 
INSERT, DELETE, UPDATE, RETRIEVE, and RETRIEVE-COMMON. There are only 
five aggregate operators supported: AVG, SUM, COUNT, MAX, and MIN. The details of 
how the other four queries are constructed and how they work are explained in thesis 
research by Clark and Yildirim. [Clark, 951. 


E. THE KERNEL DATABASE STRUCTURE 

A RECORD is a set of attribute-value pairs. Within a record, attribute-value pairs 
must have unique attribute-value names. That is, no two attribute-value pairs can have the 
same attribute-value name. At least one of the attributes in the record is a key. Following 
these two rules ensures each attribute-value pair is single valued and each record can be 
identified by at least one key. A record is enclosed by parenthesis. The attribute-value 
pairs are contained within these parenthesis: (<COURSE, CS4322>, <INSTRUCTOR, Hsiao, 
<SECTION, 2>, <YEAR, 1995>, <SEMESTER, fall>). 

A FILE is a collection of records that share unique set of attributes. If a record 
belongs to a certain file, then the first attribute-value pair of the record will contain the 
attribute TEMP and the corresponding file name. All records belonging to the same file 
will have the same first attribute-value pair. For example, (<TEMP, NAMES>, 
<LNAME, Hsiao, <FNAME, David >, <MIDDLE, K>) indicates that the record belongs 
to the file NAMES. The file contains a detailed description of the ABDM and ABDL. 

In the kernel data model, the system uses only template files (i.e., .t files) and 
descriptor files (i.e., .d files). The schema files belonging to the data model and data language 
interfaces outside the KDS generate the template and descriptor files necessary for 
mapping an interface modelAanguage into the kernel data model/data language. The 
ABDM, being the kernel model, does not need its own schema for mapping to itself. 
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The template and descriptor files (i.e., the .d and .t files) are used to describe the 
structure of the attribute-based database. It is these files which tell the kernel database 
system what the template names are and the attributes contained within a template. 
Furthermore, the attribute type, and any constraints on these attributes, will be noted in 
these files. A template can be thought of as the name of a relation in a relational database. 
The template file lays out the tables that will be used to form relationships between data in 
terms of columns, column headings and rows. The template fiile contains the name of the 
database, followed by the number of templates within the database. After the number of 
templates, the next number in the template file is the number of attributes in template. 
Attributes are listed in the template file along with their respective type (i.e., string, integer, 
etc.). Once all attributes for a template are listed, the number of attributes in the next 
template is listed, followed by the next template’s name. This process is repeated until all 
the templates and attributes have been listed. The User Manual, Appendix A, details the 
process for creating a template file. To support object-oriented database research, the 
research team created a demonstration database called FACSTU (Faculty and Student). 
FACSTU is the object-oriented database created by associated thesis teams. For more 
details on the development of the FACSTU database, see the associated thesis. 


F. IN SUMMARY 

The overall language-interface structure consists of the four LIL, KMS, LIC, and 
KFS modules. These four modules are specifically constructed to support a particular data 
model and data language. The multimodel/multilingual database system can support 
different data models and data languages provided a unique set of these four modules can 
be constructed to support the desired data model and data language. As long as a compiler 
(KMS) can be constructed that will translate the UDM to KDM the KDS can support the 
UDM/L. KDS represents the kernel database system constructed from attribute-value pairs, 
records, and files unique to the multibackend database supercomputer and the multimodel/ 


15 




multilingual database system. By designing and implementing a unique language interface, 
users can create and access a database using the desired data model/language. But, the 
system stores only one set of data. The system stores the data in the kernel-data-model form 
of attribute-value pairs [Hsiao, 91]. 
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IV. THE KERNEL DATABASE SYSTEM 


Developing a user data model and data language interface (UDM/L) between the user 
and the Kernel Database System (KDS) requires an understanding of the system’s design. 

The KDS is the portion of MODEMS software containing the Test Interface (TI). The H is 
the only portion of the software the user interface will communicate with. Development 
requires only minor changes to the TI and does not require any changes to the rest of the 
KDS. But, development does require an understanding of TI requirements. The following 
describes the KDS for a more thorough understanding of how TI works and why. 


A. OPERATING SYSTEM SUPPORT FOR KDS 

M^DBS is written in C running on the SunOS UNIX operating system version 

4.1.1. SunOS provides the C shell which M^DBS uses to maintain job control. In UNIX, 
the shell serves as an interface between the user and the operating system. The shell 
receives commands and arranges to have them executed. The shell scripts, or interpreter 

files (startcntrl, run.be, stop.db*, zero.db*, etc.), supporting M^DBS are designed to run 
on the C shell. 

The M^DBS software interacts with the Multibackend Database Supercomptuer 
hardware through a set of approximately one hundred system calls provided by UNIX. The 
UNIX operating system supports process control, reliable inter-process-communication, 
broadcast communication, and a compiler [Watkins, 93]. System calls from the kernel are 
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used for tasks like file I/O and process execution. MDBS constructs its higher level 
functions from the eighteen system calls listed below: 

Table 1: System Calls Made By MDBS 


System Call 

Purpose 

Location 

accept 

accept a connection on a socket 

pcl.c, sndrcv.c 

bind 

bind a name to a socket 

ack.c, pcl.c, sndrcv.c 

close 

delete a descriptor (file or socket) 

many places 

connect 

initiate a socket connection 

pcl.c, sndrcv.c 

exit 

terminate a process 

many places 

gethostname 

get the name of current host 

bget.c, bputc, cget.c, cputc 
dbl.c 

getnetbyname 

get access to the network 

pcl.c 

getpid 

get a process identification number 

generals.c 

gettimeofday 

get the date and time 

generals.c 

kill 

send signal to a process 

shell scripts 

listen 

listen for connection on a socket 

pcl.c, sndrcv.c 

Iseek 

move the read/write pointer 

cpcount.c, dio.c, dicp.c, 
rectag.c, zero.c 

Open 

open a file for reading or writing 

many places 

read 

read input (files or sockets) 

cpcount.c, dio.c, disp.c, iig.c, 
meta.c, pcl.c, rectag.c, sndrcv.c 

send 

send a message from a socket 

ack.c, cb.c, sndrcv.c, others 

socket 

create an endpoint for communica¬ 
tion 

ack.c, pcl.c, sndrcv.c 

unlink 

remove directory entry (file or 
socket) 

sndrcv.c, gsmodset.c 

write 

write output (file or socket) 

bes.c, cpcountc, dio.c, 
iigdbLc, meta.c, pcl.c, rectag.c, 
sndrcv.c 
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B. C LIBRARY HEADER FILES INCLUDED 

The M^DBS code references the seventeen system-supplied header files listed 

below. 

Table 2: Header Files Referenced By MDBS 
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The configure.h header file, is the header file that determines library functions, the 
names of symbols, the format of data structures, and the specification of communication 
sockets. 


C. CONTROLLER AND BACKEND PROCESSES 

The parallel architecture of M^DBS is dependent upon communications. There are 
constant communications going on between the processes running on one workstation and 
the processes running on different workstations. The workstation acting as the “controller” 
depends on reliable inter-process communications to coordinate the actions of the six 
processes running concurrently on it. Each backend machine depends on reliable inter¬ 
process communication to coordinate the actions of their six backend processes. These Six 
backend (BE) processes and six control (CNTRL) processes are executing continuously 
while MDBS is running. 


26827 pO 10:00 /dbll/u/indbsA^erE.6/CNTRL/sciitgpcl.out 

26829 pO 10:00 /dbll/ii/mdbsA^erE.6/CNTRL/sciitppcl.out 

26830 pO 10:00 /dbll/u/indbsA^erE.6/CNTRL/pp.out 

26831 pO 10:00 /dbll/ii/mdbsA^erE.6/CNTRL/ife.out 

26832 pO 10:00 /dbll/u/indbsA^erE.6/CNTRL/reqprep.out 
26839 pO 10:01 /dbll/u/mdbsA^erE.6/CNTRL/dbUi.out 

26828 pO 10:00 /dbll/u/mdbsA'^erE.6/BE/sbegpcl.out 

26833 pO 10:00 /dbll/u/mdbs/VerE.6/BE/dirman.out 

26834 pO 10:00 /dbll/ii/mdbsA^erE.6/BE/cc.out 

26835 pO 10:00 /dbll/ii/mdbs/VerE.6/BE/recproc.out 

26836 pO 10:00 /dbll/ii/mdbs/VerE.6/BE/dio.out 

26837 pO 10:00 /dbll/ii/mdbsA^erE.6/BE/sbeppcl.out 


Figure 4: Six Controller (CNTRL) and Six Back_End (BE) Processes. 


D. PROCESS FUNCTIONS 

There are twelve M^DBS processes relating to communications between the 
controller and its associated backends. These processes are depicted in Figure 4 and Figure 
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5. Controller processes include “controller get” (CGET), “controller put” (CPUT), “test 
interface” (TI), “request processing” (REQP), “insert-information generation” (IIG), and 
“post processing” (PP). The six backend processes are backend get (BGET), backend put 
(BPUT), record processing (RECP), concurrency control (CC), directory management 
(DM), and disk input/output (DIO). All six of these processes run on each backend machine 
participating in MDBS. 

The controller processes form the interface between the user and the collection of 
associated backends. The TI process is the user interface. TI routines activate the selected 
interface and capture the user’s instructions from the terminal. REQP routines parse the 
user’s requests and check for proper format and syntax. The EG process handles the 
clustering of the database records across the backend machines. Managing a global table of 
locality information (backend number, cylinder, track) is handled by the IIG. The PP 
formats the results received from the backend machines for display to the user. The CPUT 
process sends messages across the ethemet to other MDBS workstations. The CGET 
process receives messages from the controller and inter-machine messages from other 
workstations functioning as the backends. 

The backend processes are replicated on each backend machine. They form the 
interface between the controller and the individual backend. Where BGET receives 
messages from the associated workstations in the controller or backends across the 
ethernet, BPUT sends messages from an individual backend across the ethemet to the 
controller and other backend workstations. The BGET process also receives these same 
inter-machine messages for its backend machine. The RECP process manipulates records 
including selection, retrieval, and value extraction. The CC process maintains the meta¬ 
data and the base-data (record) integrity during the processing of transactions. The DM 
process manages all access to the meta-data disk. DM coordinates with RECP formulation 
and gathering information about how the records are stored. Finally, the DIO process 
manages reads and writes on the base-data (record) disk. 
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Figure 5: MDBS Communication Channels 
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Figure 5 shows how these twelve coiumunication processes interface with each 
other. In Figure 5, inter-process communication links have arrows showing which process 
initiates the link. That is, the arrows show initiation of information flow, not the direction 
of information flow. All of the communication channels depicted are established during 
“start-up”. 


E. TI LINKS BETWEEN KERNEL AND NON-KERNEL CODE 

Adding a new user interface requires minor modifications to TI. There are critical 
linkages between the kernel and non-kernel interfaces contained within the test interface 
(TI) code. 

a. The LanglFJFlag must be visible to the compiler. 

To accomplish this, be sure the “#define LangIF_Flag” statement in the 
“Flags.def ’ file located in the TI directory is not commented out. 

b. Ensure there is a function call to initialize the specific non-kemel 
language inteiface. 

To accomplish this, load the schema for the non-kernel model by calling 
the “creat_?_db_list” (e.g., creat_oo_db_list) function around line 90 in the ti.c file. 

c. Add a menu choice and call to the main procedure for the new language 
interface. 

To accomplish this, the code should be placed within the while loop 
following the function call to initialize the interface. 

d. Recompile the tuexe file. 

To accomplish this may require some minor modifications to one or more 
makefiles. The new language interface should be included in its own directory under “src” 
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inside the Lang_IF directory. The makefiles are adjusted to include a path to these files.. 
For more information on the design of a non-kernel language interface, see [Bourgeois, 1992]. 


F. IN SUMMARY 

The KDS is supported by a select group of operating system, system calls, by 
library files packaged with C, and by communications between twelve continuously 
running processes. From the KDS viewpoint, adding a new interface requires only making 
minor modifications to the ti.c file and the makefiles. By following the protocols of the ti.c 
file, there is no need for the developer to go beyond TI into the system. TI is the gateway 
to the Kernel System. An understanding of the system calls, library functions, 
communication processes used by the system aids in understanding the development of 
new language interfaces. In the next chapter, the INSERT command is analyzed. How the 
system inserts new records, individually and in mass, will be detailed. 
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V. THE INSERT OPERATION 


The INSERT is the most fundamental operation of the five basic operations 
available in the KDS. The INSERT operation is fully functional and requires no 
modifications. The INSERT operation works correctly and will support the object-oriented 
interface without any further modifications or adjustments. 


A. INSERT DESIGN CONSIDERATIONS 

The MODEMS is a one user, and “one-time” interface. The MODEMS by design 
will allow only one database to be in operation at any given time. Therefore, whenever the 
user makes any changes to the database in use, after the change is complete the backends 
release their linkage to the database. After completing an INSERT, the system completely 
exits the current operation and awaits the next command. The user must re-initiate the 
INSERT function to add anymore data. To execute a request for any other database other 
than the database in use requires the user to exit from the system. The INSERT operation 
can only occur within the context of a single database. 

As detailed in Chapters IE and IV, (see Figure 1, Figure 4, and Figure 5) there are 

two major systems in MODEMS, the Controller and the Eackends. These two systems share 
twelve processes when executing the INSERT operation (as detailed below in Figure 6). 
To execute an INSERT, the database environment must exist on the backends. To create a 
database the user must first generate a Template file (e.i., the “.t” files) and a Descriptor file 
(i.e., the “.d” files) using the DDL compiler. How to create these files from within the 
attribute-based database system (i.e., the KDS) is detailed in the User Manual (Appendix 
A). The compiler will copy the Template and Descriptor files to the backends 
automatically. These files are necessary because they provide the syntax and the Insert 
Process Communication Paths environment for error checking and maintenance of the 
relationships between the attribute value pairs. 
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B. 


THE INSERT OPERATION 


Every process and request in the MODEMS starts at the Test Interface (TI). The TT 
is the gateway into KDS. Every operation must follow the constructs and protocols of TI. 
Figure 6 and Figure 7 show graphically the system calls occurring as an INSERT executes. 
The UDM and UDL interface with KDS through a function called TI_SELECT(). Each 
Language Interface must select the Test Interface as the first step in executing operations 
that effect the database. The object-oriented language interface module is unique because 
the OODDL and OODML include the RTM. The RTM, embedded in the LIC, is the 
interface to the TI. 

The TI_SELECT() function is used to initiate TI-execute(). TI-execute() is a 
function that sends message traffic to or receives message traffic from the MDBS. 
Message traffic consists of two pointers: the database identification pointer (dbid) and the 
trafficid. The trafficid is the pointer identifying the transaction as an INSERT operation. 
The TI initiates the execution of the INSERT by sending the traffic unit to Request 
Preparation (REQP). If the system can complete the INSERT request statement, it will then 
call REQP using the TI_S$TrafUnit() function. 

The TI_S$TrafUnit() function passes its two arguments, the database name and 
INSERT request, as function parameters to REQP (Figure 8). REQP then checks for proper 
format and syntax using the PARSER() function. PARSER() calls Chk_ParsedTrafUnit() 
to ensure the INSERT request is using the correct database name, attribute name, and 
attribute value type. If there are no errors, REQP will send the traffic unit identifying the 
database and the transaction INSERT to the backends for processing. 

During these processes, the INSERT Information Generation (IIG) process (see 
Figure 6) is handling clustering of the database records across the backend system. The IIG 
ensures each backend includes a global table of locality information containing addresses 
detailing backends, cylinders and track numbers. 
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Figure 7: Test Interface Process Detail During INSERT Operations 
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Meanwhile, Concurrency Control (CC) (Figure 9) is maintaining the integrity of the 
meta data and the base data. CC initializes a series of tables to maintain concurrency 
control: the Traffic-Unit-to-Attribute-Identification Table (TUAT), the Attribute- 
Identification-to-Traffic-Unit Table (ATUT), the Traffic-Unit-to-Descriptor- 
Identification-Sets Table (TUDIST), the Traffic-Unit-to-Cluster-Identification Table 
(TUCT), and the Cluster-Identification-to-Traffic-Unit Table (CTUT). CC then executes 
the C_New_TrafficUnit(), CSCC_NewTrafficUnit(), or the DSCC_NewTrafUnit() 
functions based on what type of message the CC received from the Language Interface 
Controller or the other backends. 

The Directory Manager (DM) (Figiue 10) manages all access to the meta data disk. 
The DM receives Traffic-Unit messages from REQP finding the descriptors satisfying the 
INSERT operation. The DM then calls the INS_DESC_SR() function. At the same time, 
the DM coordinates with Record Processing (RECP)(Figiue 11) the gathering of 
information about how the base data is to be stored. The DM, after coordinating with 
RECP, then broadcasts the descriptor-identification to the other backends. 

The RECP manipulates the base data using functions for selection, retrieval, and 
value extraction. RECP receives the INSERT request from the REQP in the kernel or from 
the other backends. To execute the INSERT, the RECP fetches a Track Buffer (TB) and 
then gets free disk area from the Disk InpufrOutput (DIO)(see Figure 6) by calling the 
INS_Processing() function. The DIO handles all reads and writes to the base data disks. 
RECP then puts the records into the fetched TB and stores the TB back to the free disk area 
by calling the IP_INSERT_Record() function. 

The Post Processing (PP) (see Figure 6) properly formats the results. The results are 
received from the backends and sent through the TI to the LIC contained in the UDMAJDL. 
The LIC will call the KFS for display of the information back to the user. In the case of the 
object-oriented interface, the RTM receives the results from the PP. The RTM then calls 
the KFS to properly format the results for display to the user. The KFS and RTM are 
discussed in Chapter VI. 
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Operations 
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Figure 10: Directory Management Process Detail During INSERT 
Operations 
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Figure 11: Record Processing Process Detail During INSERT 
Operations 
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C. THE MASS_LOAD FUNCTION 

The INSERT function, as written is limited. The function allows only one record 
INSERT to occur at a time. There are no utilities for loading several records at a time. The 
Mass_Load() function solves this problem. As the name implies, the Mass_Load function 
batch loads large quantities of user generated data from a data file to the backends. 

To use the Mass_Load function, the user must first generate a Template file (i.e., 
the “.t” files) and a Descriptor file (i.e., the “.d” files) using the DDL compiler. The 
compiler will copy the Template and Descriptor files to the backends automatically. These 
files are necessary because they provide the environment that will maintain the 
relationships between the attribute value pairs. When completed, the user can then initiate 
the “User generatedData File” selection from the menu. This selection is a necessary first 
step in a hierarchy of steps that will batch load data stored in files to the current backends. 
The user will then observe after selecting “User_generatedData File” the selection menu 
has an option “M” which when selected will process the Mass_Load() function. Figure 12 
is an example of “User generated datafile” produced by the Mass_Load() function. The 
data file separates each piece of data with a space and an ampersand (@) symbol. 


FACSTU 

@ 

Name 

N1 dan a kellett 
N2 taewook k kwon 
@ 

All 17_mervine_dr monterey ca 93940 
A2 397_ricketts_rd monterey ca 93940 
@ 

Person 
PI N1 A1 m 
P2 N2 A2 m 

@ 

$ 


Figure 12: User Generated Data File using Mass_Load () 
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The Mass_Load() function is a process consisting of four steps. First, the function 
will open the “User_generated datafile” and check for a match between the database name 
in the file and the name of the database currently in use. The function will read the first 
capital letter as the name of the current executing database. The function will then check to 
see if the database name in the file is in agreement with the database name currently 
executing. These must agree or the function will abort. If the names match, then the next 
data read is recognized as the template name. The function will then open the template 
already on the backends using the “other pointer process” embedded within the function. 

Next, the Mass_Load() function will read the data from the “User generate data 
file” one by one. With each read, the function will read an attribute name from the template 
file. The matching of a data element and an attribute name will create the attribute value 
pair. As pairs are created, the function creates an INSERT statement in the attribute data 
language for each individual item read. This processing continues until the ampersand (@) 
is encountered. 

The ampersand (@) symbol acts as the demarcation between templates. When 
encountered the Mass_Load() function will stop processing, read the next template. The 
reading of data resumes. Processing continues until the dollar ($) symbol is encountered. 
The dollar ($) symbol marks the end of the file. 

Once the end of file is encountered, the Mass_Load() function passes the INSERT 
request statements to REQP in the Kernel System. The REQP receives these INSERT 
statements through the TI and checks each statement for proper format and syntax. If all 
of the statements pass the error checking, the INSERTS are executed and completed. 


D. SUMMARY 

The INSERT operation is the most basic operation of the five database operations 
available in the KDS. The INSERT operation is supported by the twelve processes 
discussed in Chapter IV. Because the INSERT operation will only operate on a single entry. 
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and there are no utilities within the system to groups of data, the Mass_Load() function is 
provided. Using Mass_Load() the users can load data from data file in batch mode. The 
INSERT and Mass_Load() functions are operational and require no modifications to 
support an object-oriented interface. 
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VI. THE KERNEL FORMATTING SYSTEM 

There are two thesis closely associated with this thesis: The Object Oriented Real- 
Time Monitor, by Erhan Senocak [Senocak, 1995], and Manipulating Objects in the 

MODEMS, by Robert Clark and Necmi Yildirim [Clark, 1995], Where this thesis only deals 
with the INSERT operation, Clark and Yildirim deal with the other four associated 
operations. These four operations are associated with manipulating the data once the data 
is appended to the database. Senocak discusses how the queries formed by the four basic 
operations are translated from the compiler to KDS required formats using a Real-Time 
Monitor (RTM) pictured below in Figure 13. He also deals with how the results of the query 
coming from the KDS are passed to the Kernel Formatting System (KFS) for display. 
During this associated research, it became obvious that the KFS required modification. We 
took on the task of completing these modifications while the other groups continued their 
research. 

A. MODIFICATIONS TO THE KFS 

As explained in Chapter IV, there are twelve M^DBS processes relating to 
communications between the controller and its associated backends (see Figure 5). One of 
these twelve processes is the Post Processing (PP) process. This process formats the results 
of queries received by the backends. The RTM receives the PP’s results and temporarily 
creates one output file named output_f. The output file consists of a set of attribute value 
pairs which can be displayed. But, unless the reader is familiar with the ABDM and ABDL 

constructs, the results are not meaningful. This violates the M DBMS design concept. The 
results must be in a format understandable to the user of an object oriented DML and DDL. 
The user should not have to understand both the object oriented DML and DDL and the 
ABDM and ABDL. The user does not interface with the KDS. 
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THE REAL-TIME MONITOR (RTM) 



Figure 13: The Real-Time Monitor and Kernel Formatting System 
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To produce results that will be understandable to the user, we modified the existing 
display format associated with the KFS. We modified the KFS to present answers to queries 
in a table format vice attribute-value pairs. The table format is clear. Answers to queries 
listed in a table of columns with headings and rows are self explanatory. Attribute names 
form the column headings, and attribute values fiU the cells of their associated attribute in 
record order. Figure 14 below is an example of query results displayed on the screen for the 
user. The figure shows Output_f file contents first. This is how the data is actually stored 
within the RTM process. Next the figure displays what the user would see if the data were 
displayed in the ADBL. The last display is an example of the table actually generated from 
the KFS after the answer to a query is passed to the KFS through the RTM. We converted 
the KFS display format from an attribute-based format to a table format to help the user 
better understand the results from queries. 

B. THE CASE FOR C++ 

Without dynamic memory allocation, displaying the results of a query in a table is 
difficult. The size of the resulting information in memory is unknown. The size of the 
required table necessary to display the information is equally unknown. Size is not fixed 
until the query is finished processing. The conventional “C” programming language does 
not easily support dynamic memory allocation. Allocation of fixed memory blocks to hold 
query answers is risky. The designer cannot predict the required size. Databases evolve and 
grow, so any valid prediction will decay over time. As designers, we felt compelled to 
introduce dynamic memory allocation to the KFS module. To do so required introducing 
the C++ programming language and the ease with which it supports dynamic memory 
allocation. Although the rest of the system is written in C, the KFS requires dynamic 
memory allocation and C++ became a necessary part of the solution. 
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To ease future research, and to ease further expansion and implementation of 
MODEMS, we recommend implementing the system in C++. C++ will facihtate further 
research in the human interface associated with the system. C++ will also facilitate 
expansion of the system by upgrading the available capabilities, libraries, and objects 
available to researchers as they investigate future designs. 


RESULTS DISPLAY 


. output_f 



(<OID, N3>,<FNAME, dan>,<LNAME, kellett>) 

(<OID, N4>,<FNAME, taewook>,<LNAME, kwon>) 

(<OID, N6>,<FNAME, david>,<LNAME, hsiao>) 

(<OID, N7>,<FNAME, thomas>,<LNAME, wu>) 


Output in Attribute Based Format 



(<OID, N3>,<FNAME,dan>,<LNAME, kelleto) 

(<OID, N4>,<FNAME, taewook>,<LNAME, kwon>) 

(<OID, N6>,<FNAME, david>,<LNAME, hsiao>) 

(<OID, N7>,<FNAME, thomas>,<LNAME, wu>) 



. New Output: Table Generated by the KFS 


OID 

1 FNAME 

1 LNAME 

N3 

1 dan 

1 kellett 

N4 

1 taewook 

1 kwon 

N6 

1 david 

1 hsiao 

N7 

1 thomas 

1 wu 


Figure 14: Query Results: Pre and Post KFS Display 
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VIL CONCLUSION 


The multimodel/multilingual database system can support different data models 
and data languages provided a unique language interface can be constructed to support the 
desired data model and data language. The overall language-interface structure consists 
of the four LIL, KMS, LIC, and KFS modules. These four modules are specifically 
constracted to support a particular data model and data language. Developing a user data 
model and data language interface (UDM/L) between the user and the Kernel Database 
System (KDS) requires an understanding of the system’s design. As long as a compiler 
(KMS) can be constmcted that will translate the UDM to KDM, the KDS can support the 
UDM/L. 

The KDS is the portion of MODEMS software containing the Test Interface (TI). A 
careful study of the KDS code, early in the research, revealed a simple design construct of 
the system: developers do not need to involve themselves in the minutia of KDS code to 
build additional model/language interfaces. The TI is the only portion of the software the 
new user interface will communicate with. Development requires only understanding the 
TI and does not require any changes to the rest of the KDS. From the KDS viewpoint, 
adding a new interface requires only making minor modifications to the ti.c file and the 
makefiles. By following the protocols of the ti.c file, there is no need for the developer to 
go beyond TI into the system. Once those protocols and constmcts are met (as they are in 
all of the other language interfaces) the rest of the system will respond. TI is the gateway 
to the Kernel System. An understanding of the system calls, library functions, 
communication processes used by the system can aid one’s understanding but is not 
required. The developer is only concerned with the protocols and constructs of the TI. 
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A. 


SUGGESTIONS FOR FUTURE RESEARCH 


1. Develop A More Sophisticated Insert Operation. 

The INSERT operation is the most basic operation of the five database operations 
available in the KDS. Because the INSERT operation will only operate on a single entry, 
and there are no utilities within the system to groups of data, the Mass_Load() function is 
provided. Using Mass_Load() the users can load data from data file in batch mode. The 
INSERT and Mass_Load() functions are operational and require no modifications to 
support an object-oriented interface. However, we believe a more sophisticated INSERT 
operation needs to be provided that allows multiple inserts in a single session without 
having to resort to batch processing from a data file. 

2. Compile The System In C-n- 

To ease future research, and to ease further expansion and implementation of 
MODEMS, we recommend implementing the system in C-H-. Implementation of the systm 
in C++ will facilitate expansion of the system by upgrading the available capabilities, 
libraries, and objects available to researchers as they investigate future designs. 

Without dynamic allocation, the simple task of displaying the results of a query is 
difficult. The size of the resulting information in memory is unknown. The size of the 
required memory allocation necessary to display the information is equally unknown. Size 
is not fixed until the query is finished processing. The conventional “C” programming 
language does not support dynamic allocation. Allocation of fixed memory blocks to hold 
query answers is risky. The designer cannot predict the required size. Databases evolve and 
grow, so any valid prediction will decay over time. 

As designers, we felt introducing the C++ programming language and its support 
for dynamic allocation would facilitate future research and aid in problem solutions. 
Because the current system is compiled in C, C++ should be able to compile the existing 
code with only minor modifications. To add the capabilities of C++ appears to justify such 


42 



an undertaking. By compiling the code in C++, C++ will provide capabilities that will 
facilitate further research in the human interface associated with the system. 

3. Its Time To Work On The User Interface. 

As the system currently exists, the user interface is inadequate. Certainly, the user 
interface does the job of reporting results to the screen and enables researchers to check 
their work. But, with the availability of gui.objects, and the the availabihty of sophisticated 
code generation programs, we believe it is time to investigate the user interface. 

Current research in human factors engineering, and cognitive sciences indicate that 
the ability to use many models within the same system will have its own unique set of user 
interface challenges. To date, no research has been done that discusses or investigates the 
potential problems inherent in a sophisticated database system that enables the users to 
draw on several models and languages at once. 

There has been no attention to date applied to how the system “looks and feels” to 
users. The interface is primitive. There has also been no research to date on an appropriate 

user interface for the M^DBMS by applying new developments in the cognitive sciences. 
We recommend a future thesis expand on the theory of cognitive sciences by applying the 

techniques of human factors engineering to the M DBMS user interface. The research 
must go beyond “looks and appearance” of the interface, and investigate the impact 
different interface styles and methods can have on the usability and cognition of a system 
that supplies so many options to the users. 

B. SUMMARY 

Using an attribute-based data model, the Kernel Database System can realize 
complex data structiues in the object-oriented data model. A single database system can 
support a variety of data models and data languages using a Kernel based on attribute-value 
pairs. In this thesis, a kernel database system supports both classical data models and data 
languages (i.e., hierarchical, network, relational, and functional) and the emerging object- 
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oriented data model and data language. By successfully creating an object-oriented 
database in the KDS, this thesis shows that complex data structures found in the object- 
oriented data model can be realized as a kernel database in a single database system. Prior 
to this research, it has not been clear whether or not the Kernel Database System (KDS), 
designed to support classical databases, can support the complex object-oriented database. 
This thesis has shown that object-oriented data can be inserted into a Kernel Data base 
consisting solely of attribute-valued pairs. The object-oriented database model and 
language are supported by the INSERT operation in the attribute-based data definition 
language (ABDL) without any modifications having to be made to the KDS. It is, 
therefore, unnecessary to build an entirely new object-oriented database system to support 
an object-oriented database. 
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APPENDIX A-THE USER MANUAL 


The Multi-Model, Multi-Language Database Management System is located in Lab 500 of 
Spanagel HaU at the Naval Postgraduate School, Monterey, California. The Lab is supported by 
two sun workstations operating from a Sun 4/110. Work Station dbl 1 contains the user interface 
and controller software, corrunonly referred to as the “front-end”. Work Station dbl3 contains the 
storage disks and associated memory management software commonly referred to as the “Back 
ends”. Work Station dbl2 is co-located in the lab and is available for use as a second “back end” 
if the need arrises. These resources are dedicated to Database Engineering research. 

These instructions will walk you through how the system is used. Before using the system 
the user must first create all the schema files and construct the optional Request files. After 
creating these, the user can begin research within the MDBS system. For more detail on the 
system architecture, and on function logic, see the related theses listed in Appendix 1 of this thesis. 
In the following instructions, letters in bold represent Prompts. Italics represent required entries 
by the user. 

Before using the system, a brush up on “vi” and “emacs” is recommended. The system does 
not support XWindows or Lemacs. Editing fi:om the system is facilitated by a basic knowledge of 
Unix text editors. To transport files from the system to a personal account elsewhere in Unix, 
requires using FTP procedures. The system will not simply copy (“cp”) from one terminal to the 
other. 

Before editing any code, remember, the program code is complex and weighty. Errors 
introduced into the code by careless management of upgrades will be difficult and time consuming 
to debug. We suggest a copy of the system be made and experimented on, tested and debugged, 
before committing to any permanent changes to the original system. 


A. LOGGING ON 

1. Remote Log On 

You can remote log-on to the MDBS from any terminal on the Computer Science 
Department’s Unix network. You start by entering “r/ogin dblV’ at the terminal prompt. The user 
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first sees a security warning message, and the Password prompt appears. Figure A-1 is an example 
of what you will see. By pressing the return key Login incorrect and Login prompts appear. Do 
not worry about the “Login incorrect”, press Enter and when Login reappears enter the Host name 
'‘mdbs” and then following the prompts, enter the password. 


4:4::|:4:4;4:4:4:4:4: WARNING ********** 

UNAUTHORIZED USE OF THIS DEPARTMENT OF DEFENSE (DOD) INTEREST 
COMPUTER SYSTEM AND/OR SOFTWARE IS PROHIBITED BY PUBLIC LAW. 

USE OF THIS SYSTEM CONSTITUTES CONSENT TO MONITORING 
CLASSIFIED PROCESSING ON TfflS SYSTEM IS PROHIBITED ****** 

Password: 

Last login: Tue Apr 4 08:50:30 on console 
mdbs processes running on dbll: 
users logged on to dbll: 

8:59ani up 35 days, 23:21,4 users, load average: 0^0,0*27,0.04 
User tty login® idle JCPU PCPU what 
mdbs console 8:50am 8 35 35 twm 
mdbs ttypO 8:51am 3 5 2 -sh 

mdbs ttypl 8:58am w 

Fig A’l: Login process on the dbll machine. 

Following these instructions activates the proper associated accounts automatically. The 
system logs into the default directory (dbll/u/mdbs) automatically. The mdbs account is used 

primarily for thesis research. There are numerous directories from which the M^DBMS system 
runs. Options exist to predetermine the number of backends that the user desires to use while 
running a particular database application. Due to constant manipulation and changes that occur 
from thesis research, our focus will be placed on using the kwontw, and badgett account on the 
dbll terminal. Entering the unix command “fe”, lists all the current accounts on the dbll 
terminal inside the mdbs directory. Look for current account on the dbll terminal in the Fig A-2. 
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(lbll/u/mdbs> Is 


Calendar/ RunData/ andy/ erhan/ master/ 

Demo/ Sockets/ badgett/ greg/ necmi/ 

Docs/ ThesislO/ bin/ kellett/ 0 - 0 / 

Run/ UserFiles/ dark/ kwontw/ 

Fig A-2: Current accounts on the dbll terminal (95/04/04). 

2. Direct Log On from Terminal DBll 

You can directly log on from terminal dbll in Lab 500. The process is the same with the 
exception of using the “rlogin” command. Do not use rlogin. Simply enter your name at “dbll 
login:”. When “password:” appears after the government’s seciurity warning, press Enter. “Lt^n 
incorrect” will then appear. Ignore this and enter “mbds'\ When the password prompt reappears 
enter the password. 


B. AFTER LOGGING ON 

1. Copy the schema and request files 

The subdirectory UserFiles contains the schema and request files for the existing 
databases. If your database exists, its files will be listed here and is ready to be processed. 
Otherwise, if the database files are not listed then you must either create them or transfer them into 
the UserFiles subdirectory. The UserFiles subdirectory can be visited from any location within 
the system by entering ''data” at the prompt. 


2. Kill any MDBS processes still running on the system. 

Prior to executing the command start or begin you must verify that there are no processes 
still running the MDBS system. The UNIX command "ps ax” will display all active processes 
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on your terminal whether you own those processes or not. Because an aborted run of the MDBS 
system can leave MDBS processes still running, the “ps ax” conunand will help locate these 
processes and by using the UNIX command “kill”, you can stop the lingering processes. Look for 
any process like those highlighted in Figure A-3. 

A second method for killing extraneous processes is to use the “stop.cmd' command. This 
command will find all the extraneous processes running and safely end them as shown in Fig A-4. 


PID TT STAT TIME COMMAND 

0?D 0:41 swapper 

1?IW 0:03/sbin/init- 

2 ? D 0:10 pagedaemon 

55 ? S 3:40 portmap 

58? IW 0:00keyserv 

63 ? S 11:43 in.routed 

80 ? IW 0:03 syslogd 

88? IW 0:14/usr/lib/sendmail-bd-qlh 

95 ? IW 0:00 ipc.statd 

96? IW 0:00 ipc.lockd 

103 ? S 3:18 /usr/etc/automount -m -f /etc/auto.master 
3099? IW 0:00 in.tnamed 
3188? S 0:00in.rlogind 
12390? IW 0:00/usr/lib/lpd 
3102 CO IW 0:00-csh(csh) 

3113 CO IW 0:00 /bin/csh /usr/bin/Xll/xinit 

3118 CO IW 0:00 /usr/bin/Xll/xinit.exec - /usr/bin/Xll/X 

3119 CO S 0:03 /usr/bin/Xll/X :0 

3120 CO IW 0:00 sh /u/mdbs/.xinitrc 

3124 CO S 0:02 xclock -update 1 -g 80x80-1+1 

3125 CO S 0:00 xterm -g 80x40+1-1 -sb -si 150 

3126 CO IW 0:00 xterm -g 80x20+1+1 -C -sb -si 150 
3138 pi IW 0:00 main 

3181 pi IW 0:00 sh -c /u/mdbs/greg/CNTRL/ti.exe 1 

3182 pi S 0:00 /u/mdbs/greg/CNTRL/ti.exe 1 
3189 p2S 0:00-csh (csh) 

3202 p2 R 0:00 ps ax 

Fig A-3: Results of executing the ps ax command. 
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dbll/ii/mdbs> stop.cmd 
stopping processes on back end dbl 1 

killing 26827 26828 26829 26830 26831 26832 26833 2683 3118 
Fig A-4: Results of the stop.cmd command. 

dbll/ii/mdbs> stop.cmd 
stopping processes on back end dbl 1 
killing no processes 

Fig A-5; Results of the stop.cmd command with no MDBS processes running. 

If the stop.cmd command is issued and no MDBS processes are running on the system, the 
user will be notified that there are no MDBS processes to kill as shown in FigA-5 

3. Perform META-DISK Maintenance. 

Upon verification that no extraneous processes are running, unless the user wants to use a 
database already on the system, the user must ensure old databases have been removed from the 
Meta-disk. This is accomplished by using the alias “pry”. “pry" checks the Meta-disk and ensures 
no data is on it. The “pry" command will display what data is on the disk. If the line displays 
zeroes, or the system returns the statement “no data is on the controller”, then the data disk is clean 
and you are ready to execute the MDBS system. If there is an existing database stored on the disk, 
the results of the “pry" command will look similar to Fig A-6. 

000000 N0\0 003 E M P R E C\DNO\0\D\0\0\ 

0000016 M)\0\D\0\0\D\0\0\ONO\0\0\0\D\0\0 

Fig A-6: Meta-disk with existing data 
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The “zero” command cleans the meta-disk of any existing data. To avoid unexpected 
crashes of the system during execution, it is best to ensure the meta-disk is clean. Fig A-7 displays 
what the user sees after executing the “zero” command. 


dbll/u/mdbs/run-39>zero 

No match. 

No match. 

File to zero = /dev/sdlc 
File size = 105638400 
Bytes to zero = 8000000 
Bytes written... 

819200 

1638400 

2457600 

3276800 

4096000 

4915200 

5734400 

6553600 

7372800 

8000000 


Fig A-7: Result of the zero command 


Provided the you have either cleaned the meta-disk, or plan to process an existing database, 
you are now ready to run the MDBS system. From any MDBS directory, type the command “start” 
or “begin” to start the MDBS interface. 

4. Set Up The User Screen. 

We recommend opening two separate C shells while operating the MDBS system. This will 
facilitate trouble shooting and research. One shell is used strictly for database execution. The other 
shell is used for checking the UserFiles directory. The UserFUes directory should be checked to 
ensure all necessary database files exist. After checking the directory, use this same screen to verify 
all processes are running. 
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5. Check to see if all processes are running. 

When running the MDBS, six backend (BE) processes and six control (CNTRL) processes 
should be running. These processes are shown in Fig A-8. If all the processes are not running, then 
exit the system pressing [Control]-c. After exiting, kill any extraneous processes with the 
“stop.cmd” command. Double check to ensure no extraneous processes are running using the “ps 
ax” command, ensure the data disk has been zeroed. If not, zero the meta disk with the “zero” 
command. Restart the MDBS system with the “begin” or “starf\ 


26827 pO 10:00 /dbll/u/mdbs/VerE.6/CNTRL/scntgpcl.out 

26829 pO 10:00 /dbll/u/indbs/VerE.6/CNTRL/scntppcl.out 

26830 pO 10:00 /dbll/u/mdbs/VerE.6/CNTRL/pp.out 

26831 pO 10:00 /dbll/ii/mdbs/VerE.6/CNTRL/iig.out 

26832 pO 10:00 /dbll/u/indbs/VerE.6/CNTRL/reqprep.out 
26839 pO 10:01 /dbll/u/mdbs/VerE.6/CNTRL/dblti.out 

26828 pO 10:00 /dbll/u/mdbs/VerE.6/BE/sbegpcl.out 

26833 pO 10:00 /dbll/u/mdbs/VerE.6/BE/dirinan.out 

26834 pO 10:00 /dbll/u/mdbs/VerE.6/BE/cc.out 

26835 pO 10:00 /dbll/u/mdbs/VerE.6/BE/recproc.out 

26836 pO 10:00 /dbll/u/mdbs/VerE.6/BE/dio.out 

26837 pO 10:00 /dbll/u/mdbs/VerE.6/BE/sbeppcl.out 


Fig A-8: Six Controller (CNTRL) and Six Back_End (BE) Processes. 


C. RUNNING M^DBMS 


The attribute-base data model (ABDM) is the kernel data model (KDM) for the M^DBMS system. 
The ABDM was chosen as the kernel data model because ABDM allows you to store the meta data 
and base data separately. ABDM introduces equivalence relations which partition the base data 
into mutually exclusive sets called clusters. These clusters are distributed across the backends 
allowing parallel access to the base data. Coupling ABDM with the attribute-based data language 
(ABDL) as the kernel data language (KDL) facilitates database design. The attribute-based model and 
language support database research with a semantically rich and complete language and with a 
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simple storage and parallel processing architecture. For more information on how M DBMS can 
support classical and emerging database designs see Chapters 2, 3,4, and 5 of this thesis. 


1. Database Constructs 

Data in the ABDM is stored as an attribute-value pair. Attribute-value pairs are the simple 
building blocks of the kernel database. The attribute-value pairs consist of attribute names and 
corresponding values. When displayed, an attribute-value pair is enclosed by a pair of angled 
brackets. The attribute name is always first, followed by the value for the attribute. If the attribute- 
value pair has no value, then only the attribute-name is seen. An example would be <FNAME, 
Tae-wok>, were “FNAME” is the attribute name and “Tae-wok” is its corresponding value. The 
attribute name must always be uppercase. 

A RECORD is a set of attribute-value pairs. Within a record, attribute-value pairs must have 
unique attribute-value names. That is, no two attribute-value pairs can have the same attribute- 
value name. At least one of the attributes in the record is a key. Following these two rules ensures 
each attribute-value pair is single valued and each record can be identified by at least one key. A 
record is enclosed by parenthesis. The attribute-value pairs are contained within these parenthesis: 
(<COURSE, CS4322>, <INSTRUCTOR, Hsiao, <SECTION, 2>, <YEAR, 1995>, 
cSEMESTER, fallx 

A FILE is a collection of records that share unique set of attributes. If a record belongs to a 
certain file, then the first attribute-value pair of the record will contain the attribute TEMP and the 
corresponding file name. All records belonging to the same file will have the same first attribute- 
value pair. For example, (cTEMP, NAMES>, <LNAME, Hsiao, <FNAME, David >, 
<MIDDLE, K>) indicates that the record belongs to the file NAMES. The file contains a detailed 
description of the ABDM and ABDL. We encourage the user to read these prior t executing the 
attributed-based interface. 
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2. Generating A Database Operation 

The user can start the execution of the ABDM interface by selecting the option (a) from the 
first menu selection screen. The first selection screen will look like Fig A-9. The ABDM interface 
does not require the use of a schema file or request file. In the kernel data model, the system uses 
template files (i.e., ".t" files) and descriptor files (i.e., ".d" files). The schema files generate the 
template and descriptor files necessary for mapping an interface modelAanguage into the kernel 
data model/data language. The ABDM, being the kernel model, does not need its own schema for 
mapping to itself. 

Welcome to Multi-Lingual/MuIti>Backend Database System 

Select an operation: 

(a) - Execute the attribute-based/ABDL interface 
(r) - Execute the relational/SQL interface 
(h) - Execute the hierarchical/DL/I interface 

(n) - Execute the network/C ODASYL interface 
(f) - Execute the ftinctional/DAPLEX interface 

(o) - Execute the Object-Oriented interface 
(x) - Exit to the operating system 

SeIect-> 

Fig A-9: The First Selection Screen. 

In the ABDM interface the user creates the template and descriptor file prior to execution. 
There is an option to generate a database but using this option is unnecessarily time consuming. 
We suggest using a text editor like emacs or vi to create the template and descriptor files. 

After selecting the option (a) from The Multi-Lingual/Multi-Backend Database System 
menu in Fig A-9, selects option (g) at the next ABDL interface menu. This menu will look like Fig 
A-10. The (g) option is used to generate a new database in the attribute-based form. 
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The attribute-based/ABDL interface: 
(g) - Generate a database 


(I) - Load a database 
(r) - Request interface 
(x) - Exit to MDBS main menu 
Select-> 

Fig A-10: ABDL Interface Menu 

When the (g) option is picked, the generate-database menu (Fig. A-11) is displayed. 
This menu is the gateway to database generation. To generate a database, and be able to conduct 
operations on the database, the user must: 

a. Generate the "J" Template File. 

b. Generate the ”.d'* Descriptor File. 

c. Generate/Modify Set Values by creating the ''.s"file. 

d. Generate the ".r” Records File. 

e. Load the Database. 

The Generate-Database menu (Fig. A-11) is the main menu for these functions. 

Select an operation; 

(t) - Generate record template 

(d) - Generate descriptors 
(m) - Generate/modify sets 
(r) - Generate records 

(x) - Exit, return to previous menu (ABDL main) 

Select-> t 

Fig A-11: Generate-Database menu 
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There are five options on the menu screen. These options include: 


• Option (t): a collection of menus for generating the record-template file, which contains 
the meta-data for the different record types in our database. 

• Option (d): a collection of menus for generating the descriptor files. Descriptor files 
contain the directory attributes of the database along with possible initial values for the 
descriptors of each directory attribute. 

• Option (m): a collection of menus for generating (actually modifying) data sets for each of 
the attributes in the database. These data sets are then used to systematically generate arbitrary 
records for the database using the (r) option. 

• Option (r): a collection of menus for generating the record file. The record file contains 
a group of records that are to be mass loaded by the MODEMS. 


Together, the (m) and (r) options can be used to generate test or sample databases. Using 
option (r) creates a test, or sample database, which contains records that have been systematically 
constmcted from the sets of values created by the (m) option. Through these two options, the user 
can quickly set up a test or sample database. 


• Option (x): returns you to the previous menu. 


The next sections of this manual will describe how each of these functions is performed. 


3. Generating A Template File 

Generating the template file is the first step in creating a database on the KDS. The 
template and descriptor files (i.e., the ".d" and ".t'Tiles) are used to describe the structure of the 
attribute-based database. These files must be present to tell the kernel database system what the 
template names are and their associated attributes. For the initial creation of a database, we 
suggest that using vi or emacs for generating the ".d" and ".t" files outside the system. The system 
can be cumbersome. The following details how to create these files from within the system. 

The names of the templates and the attributes associated with each template are described 
to the database system through the template and descriptor files. The attribute type and any 
constraints on attributes will be noted in these files. A template name is similar to the name of a 
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relation in a relational database. The template file contains the name of the database, followed by 
the number of templates within the database. After the number of templates, the next number is 
the number of attributes in the following template. The template name is listed followed by the 
attributes in that template and their respective type (i.e. string, integer, etc.). Once all attributes for 
a template are hsted, the number of attributes in the next template is listed, followed by the next 
template’s name. This process is repeated until all the templates and attributes have been listed. 

The following provides the user with a step-by-step reference for executing the "generate 
the template file" operation. Remember, attribute values have to be in upper-case and every value must 
have no blanks in a single value. 

a. Generating A Template File 

If user picks the (t) option from the MODEMS selection menu the following is a 
sample of what the user should be seeing and how the process generates a template file. The 
sample is followed by the results of the process. The following is what the user will observe on 
the screen. 

Select an operation: 

(t) - Generate record template 
(d) - Generate descriptors 
(m) - Generate/modify sets 
(r) - Generate records 

(x) - Exit, return to previous menu (ABDL main) 

Select-> t 

Enter the template file name: FACSTU.t 
ENTER DATABASE ID: FACSTU 

ENTER THE NUMBER OF TEMPLATES FOR DATABASE FACSTUl: 13 

ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE#!: 5 
ENTER THE NAME OF TEMPLATE #1: Name 

ENTER ATTRIBUTE #1 FOR TEMPLATE Name: TEMP 
ENTER VALUE TYPE (s = string, i = integer): ^ 
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ENTER ATTRffiUTE #2 FOR TEMPLATE Name: OID 
ENTER VALUE TYPE (s = string, i = integer): 5 

ENTER ATTRIBUTE #3 FOR TEMPLATE Name: FNAME 
ENTER VALUE TYPE (s = string, i = integer): s 

ENTER ATTRIBUTE #4 FOR TEMPLATE Name: MI 
ENTER VALUE TYPE (s = string, i = integer): 5 

ENTER ATTRIBUTE #5 FOR TEMPLATE Name: LNAME 
ENTER VALUE TYPE (s = string, i = integer): 5 


ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE #2:5 
ENTER THE NAME OF TEMPLATE #2: Person 

ENTER ATTRIBUTE #1 FOR TEMPLATE Person: TEMP 
ENTER VALUE TYPE (s = string, i = integer): 5 

ENTER ATTRIBUTE #2 FOR TEMPLATE Person: OID 
ENTER VALUE TYPE (s = string, i = integer): ^ 

ENTER ATTRIBUTE #3 FOR TEMPLATE Person: PNAME 
ENTER VALUE TYPE (s = string, i = integer): j 

ENTER ATTRIBUTE #4 FOR TEMPLATE Person: PADDRESS 
ENTER VALUE TYPE (s = string, i = integer): s 

ENTER ATTRIBUTE #5 FOR TEMPLATE Person: SEX 
ENTER VALUE TYPE (s = string, i = integer): 5 


In the above example the user is creating the template file by answering the 
questions with values needed for the database design. The user selected "t" from the menu. The 
system asked for the name of the new template. The user responded with "FACSTU". After 
giving the system a name for the new template, the system begins to establish relationships 
between this new template and records that will be associated with it. In the example there are 
thirteen related records to FACSTU. The system then asks for the attributes and their associated 
type for the 1st, then the 2nd, etc., records. This series of questions will continue through record 
number thirteen then stop. 


b. An Example Template File (FACSTU.t) 

After creating the template files, and the thirteen related template files, the 
following results are stored in the system as the FACSTU template. 
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FACSTU 

13 

5 

Name 
TEMP s 
OIDs 
FNAME s 
Mis 

LNAMEs 

5 

Person 
TEMPS 
OID s 
PNAME s 
PADDRESS s 
SEXs 


/* template file name */ 

/* number of related templates */ 

/* number of attributes in template 1 */ 

/* template is called "name" */ 

/* "name" is an attribute template, type s */ 

/* OID is an attribute of type s */ 


This type of storage continues through template 13. 


4. Generate a Descriptor File 

After making the template files, select option (d) at the selection menu. Option (d) 
generates the descriptor files interface for the creation of descriptor files. The descriptor file 
contains information with regards to constraints placed upon the attributes within the template. In 

order to achieve the mutual exclusivity of the MODEMS, there are three descriptor types that an 
attribute can take on. Type a is an attribute which has a disjointed range of values (i.e. 0 <= 
NUMBER <= 100). Type b is an attribute of distinct value (i.e. SEX= M). Type C is an attribute 
that has a dynamic range that is determined at run time. The attribute TEMP will be a type b 
attribute whose distinct values are the template file names in the data-base. The attribute 
NUMBER (street number) is a type a attribute whose value range is from 00 to 99, from 100 to 
199, and so on. The attributes FNAME and LNAME are also type a attributes whose value range 
goes from the letter A to Z. The following is an example of the process creating a descriptor file 
for the demonstration data-base called FACSTU. 

a. Generating a Descriptor File 

After completing the creation of a template file, the main menu returns. The user 
should then select the "d" function. 
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Select an operation: 


(t) - Generate record template 
(d) - Generate descriptors 
(m) - Generate/modify sets 
(r) - Generate records 

(x) - Exit, return to previous menu (ABDL main) 

Select-> d 


The system will prompt the user with the following questions: 

Enter the template file name; FACSTU.t 

Enter the descriptor file name: FACSTU.d 

Will attribute 'TOMP' be a directory attribute (Y/N)? y 

ENTER THE DESCRIPTOR TYPE FOR TEMP (a,b,c): b 


Use '!' to indicate that no lower bound exists... Enter '(®' to stop 
Note: Must be Entered When the Lower Bound is Requested 


ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR; / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: / 

ENTER UPPER BOUND FOR DESCRIPTOR (lower bound = 
ENTER LOWER BOUND FOR DESCRIPTOR: @ 


Name 
Address 
Person 
Faculty 
CourseJac 
Civjac 
Mil_fac 
Course 
): Course_stu 
): Teamjstu 
): Team 
): Teamjac 
!): Student 
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Note that there are thirteen entries. This descriptor file creates the relationships 
between the FACSTU template and its thirteen related records. 

WiH attribute 'OID' be a directory attribute (Y/N)? n 
Will attribute 'FNAME' be a directory attribute (Y/N)? n 
Will attribute 'MI' be a directory attribute (Y/N)? n 
Will attribute 'LNAME' be a directory attribute (Y/N)? n 

... continue. 

Will attribute 'OID_F' be a directory attribute (Y/N)? n 

Will attribute 'STUDENT_NUM' be a directory attribute (Y/N)? n 

Will attribute 'MAJOR' be a directory attribute (Y/N)? n 

b. An Example Descriptor File 

Once all of these questions are answered, the system will create the FACSTU.d file. 
After creating the descriptor file,, the following results are stored in the system as the FACSTU.d 
file. 

FACSTU 
TEMP b s 
! Name 
! Address 
! Person 
! Faculty 
! Course_fac 
! Civ fac 
I Mil_fac 
! Course 
! Course_stu 
! Team_stu 
! Team 
! Team_fac 
! Student 


$ 






As can be seen, the descriptor file holds the relationships between the main template 
file (FACSTU) and the records that are related to it. Each name represents a record or tuple of 
attributes and attribute types existing in a set by that name. 

5. Generate/Modify the Set Values 

After finishing generating the descriptor files the user selects option (m) at the next 
selection menu. Selecting (m) initiates execution of the Generate/Modify Set Value files in the 
interface. The ABDL interface supports this operation for the creation of initial records to the 
database. The generated set file will be named by the user and will end with an ".s" suffix. The file 
format used in the ABDM interface resembles the initial record file with set data instead of 
attribute names underneath the template name. The End of File is marked by a $ symbol. An 
important note when creating a set file is that the system looks for TABS between attribute values in a 
record (or tuple). If the spacebar is used, the system will not read the space as the start of a new 
attribute and wiU erroneously read the generating set file. The following illustrates the process 
for the generating set file which will be used to generate initial records file. 

a. Generating a Set Value File 

These step-by-step instructions aid the user in developing a set file on the 

M^DBMS based on the template file which was generated earlier. The template and descriptor 
files must be generated prior to generating the initial records file. The following is a sample of 
the process to generate set value files which are used to generate initial records in the database. 

Select an operation: 

(t) - Generate record template 
(d) - Generate descriptors 
(m) - Generate/modify sets 
(r) - Generate records 

(x) - Exit, return to previous menu (ABDL main) 

Select-> m 
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From the main menu select the "m" option. Then, input the template file’s name. 


Enter the template file name: FACSTU.t 


CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE 'TEMP' ON TEMPLATE 'Name': 

fn) - generate a new set for it 
(m) - modify an existing set for it 
(s) - do nothing with it 

Select-> 5 


No action needs to be taken on the record name, the record will encompass the 
whole set of attributes and values. 


CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE 'FNAME' ON TEMPLATE 'Name': 
(n) ■ generate a new set for it 
(m) - modify an existing set for it 
(s) - do nothing with it 


Se!ect-> n 


The attribute FNAME belongs to the record "Name". By selecting "n" the user can 
input values to associate with FNAME. 


Enter the set file name: fname.s 

ENTER SET VALUE: Luis 
ENTER SET VALUE: Bruce 
ENTER SET VALUE: Dan 
ENTER SET VALUE: TaeWook 
ENTER SET VALUE: Recep 
ENTER SET VALUE: David 
ENTER SET VALUE: Thomas 
ENTER SET VALUE: John 
ENTER SET VALUE: @ 

Set generation completed...modify it (Y/N)? n 


The process continues until all of the records, and attributes are associated with 

values. 


CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE 'MI' ON TEMPLATE 'Name': 

(n) - generate a new set for it 
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(m) - modify an existing set for it 
(s) - do nothing with it 

Select-> n 

Enter the set fde name: mi.ss 

ENTER SET VALUE: C 
ENTER SET VALUE: D 
ENTER SET VALUE: K 
ENTER SET VALUE: M 
ENTER SET VALUE: R 
ENTER SET VALUE: T 
ENTER SET VALUE: @ 

Set generation completed...modify it (Y/N)? n 

CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE LNAME' ON TEMPLATE Name’: 
fn) - generate a new set for it 

(m) - modify an existing set for it 
(s) - do nothing with it 

Select-> n 

Enter the set file name: Iname.s 

ENTER SET VALUE: Ramirez 
ENTER SET VALUE: Badgett 
ENTER SET VALUE: Kelfet 
ENTER SET VALUE: Kwon 
ENTER SET VALUE: Tan 
ENTER SET VALUE: Hsiao 
ENTER SET VALUE: Wu 
ENTER SET VALUE: Daley 
ENTER SET VALUE: @ 

Set generation completed...modify it (Y/N)? n 

CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE TEMP' ON TEMPLATE Person’: 

(n) - generate a new set for it 
(m) - modify an existing set for it 
(s) - do nothing with it 

Select-> s 


CHOOSE ACTION TO BE TAKEN FOR 
ATTRIBUTE OH)' ON TEMPLATE Person’: 

(n) - generate a new set for it 
(m) - modify an existing set for it 
(s) - do nothing with it 

Select-> n 

Enter the set file name: personoids 


continue the rest of the tables in the same way. 
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During generate/modify sets, the user must not generate a duplicated set value. A set 
value can be used many times, but the existence of an attribute value pair is a unique event in the 
database and duplicates are not allowed. A different attribute may share the same value, but there 
must not be any attribute-value pair that is a duplicate of another. 

For the initial creation of a database, we suggest that using vi or emacs for generating 
the ".d" and ".t" files outside the system. The system can be cumbersome. However, once the 
".d" and ".t" files are created, the user must use the above steps in the generate/modify operation 
to create every ".s" file. The above steps have to be followed from within the database system. 
The system cannot find set records generated using any other method. Trying to access set records 
from outside sources will produce an error message. Also note, every generated set file’s name 
will be uppercase. The system wiU automatically translate lower case names to uppercase. The 
name of set value must be in uppercase. 

6. Generate A Records File 

After executing the generate!modify set files interface, select option (r) at the next 
selection menu. Option "r" initiates execution of the generating records files interface. The ABDL 
interface supports the generate records function for the loading of records to the database. 
Records genereated will belong to a file named after the database with an .r suffix (i.e., for 
example, FACSTU.r). 

The generate records file format used in the ABDM interface resembles the template file 
format. The only difference in the two is that the record file generator will ask for data instead of 
attribute names after receiving the template name. The database name wiU appear at the top of the 
file followed by an @ symbol. After each template, an @ symbol must be used as a separator 
between templates. The End of File is marked by a $ symbol. 

An important note: when creating a mass load file, the system looks for TABS between attribute values 
in a record (or tuple). If the spacebar is used between attributes, the system wiU not read the space as 
the start of a new attribute and will erroneously read the mass load file. The following illustrates 
the process for generating the initial records file for the demonstration database FACSTU. 
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a. Generating An Initial Records File 

The following step-by-step instructions aid in developing an initial records file on 

the MODEMS based on the template file , descriptor file, and set-value file generated by following 
the previous sections. The following illustrates the sample process to generate initial record files 
followed by the results of the process. Start by selecting "r" from the main menu. 

Select an operation: 

(t) - Generate record template 
(d) - Generate descriptors 
(m) - Generate/modify sets 
(r) - Generate records 

(x) - Exit, return to previous menu (ABDL main) 

Select-> r 

Enter the template file name; FACSTU.t 
Enter the record file name: FACSTU.r 

Note that the record file name must always be named after the database using an "r" 
extension. Otherwise, the system will not be able to associate the two files. 

ENTER THE NAME OF THE FH^E CONTAINING THE 

VALUES FOR ATTRIBUTE 'OID' ON TEMPLATE 'Name': NAMEOID.S 

ERROR: Cannot open the file. 

After entering the name of the template, the above error statement appears. Simply 
ignore this statement. The system is accumulating the number of potential records that can be 
created based on information held in the Template, Descripter, and Set-Value files. While doing 
this, the system also trys to open the file. But the file is not ready yet, so the error statement 
appears. Processing continues, therefore, ignore the statement. 

ENTER THE NAME OF THE FILE CONTAINING THE 

VALUES FOR ATTRIBUTE FNAME' ON TEMPLATE Name': FNAME.s 

ERROR: Cannot open the file. 

ENTER THE NAME OF THE FILE CONTAINING THE 
VALUES FOR ATTRIBUTE 'MI' ON TEMPLATE Name': Ml.s 
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ERROR: Cannot open the file. 

ENTER THE NAME OF THE FILE CONTAINING THE 

VALUES FOR ATTRIBUTE 'LNAME' ON TEMPLATE 'Name': LNAME.s 

3072 records can be generated for template 'Name'... 

How many records do yon want generated? 8 

ERROR: Cannot open the file, 

.... continue the above until all records have been created. 

Note, the process begins with giving the system the template name (i.e., FACSTU.t) 
then the record file name (FACSTU.r). These two must match. The system then asks for set-value 
file names that match the records it finds within the template and descriptor files. When done, the 
system will return to the main menu. 


b. An Example Records File 

By following the steps as they appear on the screen, the following is stored in 
memory in the FACSTU.r file. Not all of the entries used to make the below record file were 
shown in the example. The list of entries is lengthy and redundant. What is listed below is the 
entire record file showing each template, record, and the attribute-value pairs associated with the 
attributes listed in each record. Below is the toy database used for thesis research and in the theses 
related to this research. 

Note, the objects are related through attribute-value pairs of other template names. 


FACSTU 

@ 

Name 

N2 Luis K Daley /* N2 is a name. The name is Luis K Daley */ 

N3 TaeWook K Daley 

N8 Recep T Ramirez 

N2 Bruce K Wu 

N6 TaeWook K Hsiao 

N5 Dau C Ramirez 
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N7 John M Tan 
N6 Thomas R Kwon 

@ 

Person 

P3 N6 A1 F /* person P3 has a name (N6), address (Al), and a sex (F) */ 

P7 N8 A6 M 
P4 N8 A4 F 
P4 N8 A2 M 
P4 N1 A4 M 
P5 N1 A3 M 
P6 N1 AS M 
PI N4 A4 F 
@ 

Address 

A2 238 Mets_Dr Monterey CAA4 320 Montecito Seaside CA6 144 Montecito Seaside 
CA8 320 Brownell_Cr MontereA7 238 Spanagel_Cr SeasideA2 18 Ricketts_Rd Seaside 
A7 14 Mets_Dr Monterey CA A4 144 Mervine_Dr Seaside CA 93955 
A4 320 Montecito Seaside CA6 144 Montecito Seaside CA8 320 Brownell_Cr 
MontereA7 238 Spanagel_Cr SeasideA2 18 Ricketts_Rd Seaside A7 14 Mets_Dr 
Monterey CA A4 144 Mervine_Dr Seaside CA 93955 

A6 144 Montecito Seaside CA8 320 Brownell Cr MontereA7 238 Spanagel_Cr 
SeasideA2 18 Ricketts_Rd Seaside A7 14 Mets_Dr Monterey CA A4 144 Mervine_Dr 
Seaside CA 93955 

A8 320 BrownellCr MontereA7 238 SpanagelCr SeasideA2 18 Ricketts_Rd 
Seaside A7 14 Mets_Dr Monterey CA A4 144 Mervine_Dr Seaside CA 93955 
A7 238 Spanagel_Cr SeasideA2 18 Ricketts_Rd Seaside A7 14 Mets_Dr Monterey 
CA A4 144 Mervine_Dr Seaside CA 93955 

A2 18 Ricketts Rd Seaside A7 14 Mets_Dr Monterey CA A4 144 Mervine Dr 
Seaside CA 93955 

A7 14 Mets Dr Monterey CA A4144 Mervine Dr Seaside CA 93955 
A4 144 Mervine_Dr Seaside CA 93955 
@ 

Faculty 
P8 CS P6 
P6 CS P6 
P8 CS P8 
@ 

Civ_fac 
P6 AProfP6 
P6ProfP7 
@ 

Mil_fac 
P8 LCDR P8 

@ 

Course_fac 
SOC3 C4 P7 
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S0C3 C2 P8 
S0C2 C2 P7 
SOCl C3 P7 
@ 

Course 

C4 HCI4322 2 P8 
C4 OOPROG 4322 2 P8 
C2 HCI 4114 2 P7 
Cl DBI4203 1 P8 
@ 

Course_stu 
SOCS3 Cl P2 
SOCSIO C4 PI 
SOCS7 C2 P5 
SOCS7 C2 P4 
SOCS9 C3 P3 
SOCSIO C2 P4 
SOCS4 Cl P3 
SOCS8 Cl PS 
SOCS3 C3 P2 
SOCS6 C2 PS 
SOCSl C3 P3 
SOCS8 C4 P3 
SOCSIO Cl PS 
@ 

Teani_stu 

5051 T2 P2 
SOSS T2 PI 
SOS7 T1 PS 

5052 T1 PI 
SOSS T2 PS 

5053 T1 PS 
SOS2 T2 P3 
@ 

Team 
T2 DBS 
T2 OOP 
@ 

Team_fac 
SOT3 SOCSIO T1 
SOT2 SOCS4 T2 
SOT3 SOCS2 T1 
@ 

Student 
P3 30 CS PI 
P2 30 CS PI 
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PI 10 CS P2 
P3 10 CS P4 
P5 40 CS P2 
$ 

c. Sample Data Records (FACSTU.r) 

The following is the output of the record file. When using the ABDM and ABDL, 
the output of the file will be in the Attribute Data format seen below. 

FACSTU 

@ 

Name 

N1 Luis M Ramirez 
N2 Bruce R Badgett 
N3 Dan R Kellet 
N4 TaeWook K Kwon 
N5 Recep T Tan 
N6 David K Hsiao 
N7 Thomas C Wu 
N8 John D Daley 
@ 

Address 

A1144 BrownellCr Monterey CA 93940 
A2 320 Mets_Dr Seaside CA 93955 
A3 117 Mervine_Dr Monterey CA 93940 
A4 397 Ricketts_Rd Monterey CA 93940 
A5 238 Montecito Monterey CA 93940 
A6 12 Spanagel_Cr Monterey CA 93940 
A7 14 Spanagel_Cr Monterey CA 93940 
A8 18 Spanagel Cr Monterey CA 93940 
@ 

Person 
PI N1 A1 M 
P2 N2 A2 M 
P3 N3 A3 M 
P4 N4 A4 M 
P5 N5 A5 M 
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P6 N6 A6 M 
P7 N7 A7 M 
P8 N8 A8 M 
@ 

Faculty 
P6 CS P6 
P7 CS P7 
P8 CS P8 
@ 

Course_fac 
SOCl Cl P6 
SOC2 C2 P7 
SOC3 C3 P6 
SOC4 C4 P8 
@ 

Civ_fac 
P6 Prof P6 
P7 AProf P7 
@ 

MB!_fac 
P8 LCDR P8 
@ 

Course 

Cl DBSEM 4322 1 P6 
C2 OOPROG 4114 1 P7 
C3 DBI3320 2 P6 
C4 HCI4203 1 P8 
@ 

Course_sto 
SOCSl Cl PI 
SOCS2 C2 PI 
SOCS3 C4 PI 
SOCS4 Cl P2 
SOCS5 C4 P2 
SOCS6 Cl P3 
SOCS7 C2 P3 
SOCS8 C3 P3 
SOCS9 C4 P3 




SOCSIO Cl P4 
SOCSll C4 P4 
SOCS12 Cl P5 
SOCS13 C4 P5 
@ 

Teamstu 
SOSl PI T1 
SOS2P2T1 

5053 P3 T1 

5054 P4 T1 

5055 P5 T1 

5056 PI T2 

5057 P3 T2 

@ 

Team 
T1 DBS 
T2 OOP 
@ 

Teamfac 
SOTl P6 T1 
SOT2 P7 T1 
SOT3 P7 T2 
@ 

Student 
PI 10 CS PI 
P2 20 CS P2 
P3 30 CS P3 
P4 40 CS P4 
PS SO CS PS 
$ 


D. LOAD THE DATABASE 

Before loading the database, the template, descripter, and record files must be created. 

Executing a loading of a database on the M DBMS depends on information stored in these files. 
The backends depend on the template and descriptor files to manage the data between them. 
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Therefore, they must be loaded onto the back-end system. The following illustrates the process 
for loading the database and the results of the process on the back-end system (Workstation dbl3). 


1. Loading the Database 

The following illustrates the process of loading a database. This example is followed by 
a sample of the execution on the back-end system (dbl3). These outputs are seen by entering the 
Unix command gape on the back-end system (Workstation dbl3). 

After finishing the generate records option, the main menu reappears. Select option (1). 
Option "1" initiates database loading operations. After selecting option (i), the screen displays 
another selection menu. Choose (u). The system will ask for the database name. After entering 
the name, another selection menu will appear on screen. Selects option (r). The system will ask 
for the record file name. Enter the name of the record file. After following these steps, the system 
loads the users database on the back-end system (Workstation dbl3). 

The attribute-based/ABDL interface: 

s) - Generate a database 
f) - Load a database 
r) - Request interface 
x) - Exit to MDBS main menu 

Select-> / 

Select an operation: 

(u) - Use a database 

(r) - Mass load a file of records 

(x) - Exit, return to previous menu 

Select-> u 

Enter the name of the database: FACSTU 

Select an operation: 

(u) - Use a database 

(r) - Mass load a file of records 

(x) - Exit, return to previous menu 

Select-> r 

Enter the record file name: FACSTU.r 

<Loading Records, Please Stand By> 
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If an error message appears after entering the records name then check to ensure the data 
types match between the template and records files. Also make sure that there is no blank data 
between a single attribute value. And then user begin this process again. 


10 20 30 40 50 60 

Select an operation: 

tu) - Use a database 

(r) - Mass load a file of records 

(x) - Exit, return to previous menu 

Select-> 

The system is now loaded with the user’s defined database and is ready for manipulation 
and use. 


2. An Example of a Database Loaded on the Backend 

The database is loaded to the back-end. Our research used only one backend. But, the 
system is designed to have several working in parrallel to speed the search functions in very large 
databases. To see the following, enter the UNIX command gape on each workstation that is a 
backend and you want to view. 


dbll/u/mdbs> gape 


0000000 

0000016 

0000032 

0000048 

* 

0000416 

0000432 

0000448 

0000464 

0000480 

0000496 

0000512 

* 

0008192 

0008208 

0008224 

0008240 

0008256 

0008272 

0008288 

0008304 


Quantum ProDrive 
105S cyl 974 al 
t 2 hd 6 sec 35 \0 
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 

\0 \0 \0 \0 016 N 003 373 \0 \0 \0 \0 \0 \0 \0 001 
003 316 \0 002 \0 006 \0 # \0 \0 \0 \0 \0 \0 \0 \0 
\0 \0 ? * \0 \0 \0 M \0 \0 m 354 \0 \0 \0 \0 
\0 003 036 374 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 323 
\0 002 q 346 \0 \0 \0 \0 \0 \0 \0 \0 332 276 205 243 
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 

\0 317 \0033 lName$Nl$Lui 
s$M$Ramirez$# \0034 1 
Name$N2$Bruce$R$ 
Badgett$#\0 031 1Name 
$N3$Dan$R$Kellet 
S#\0 033 lName$N4$Tae 
Wook$K$Kwon$#\0 030 1 
Name$N5$Recep$T$ 
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0008320 

0008336 

0008352 

0008368 

0008384 

0008400 

0008416 

* 

0016384 

0016400 

0016416 

0016432 

0016448 

0016464 


Tan$#\0 032 1Name$N6$ 
David$K$Hsiao$#\0 
030 1Name$N7$Thomas 
$C$Wu$#\0 031 lNanie$N 
8$John$D$Daley$# 

& \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 

001~\0 11Address$Al$ 
144$Brownel! Cr$ 
Monterey$CA$9394 
0$#\0,1 AacIress$A2 
$320$Mets Dr$Sea 
side$CA$93955$#\0 


the system continues like this until the entire database is loaded. 


E. MANIPULATING THE DATABASE 

1. Using the ABDM Interface (REQUEST-INTERFACE) 

After a database has been loaded, and the database contains the values for each record 
desired by the designer, the database is available for manipulation. Exit the Generate a Database 
menu. The next menu will be the Attribute-BasedlABDL Interface menu shown below. 

The attribute-based/ABDL interface: 

(g) - Generate a database 

(I) - Load a database 

(r) - Request interface 

(x) - Exit to MDBS main menu 

Select-> r 


The (r) option is used to execute the request interface for attribute-based databases 
and to process ABDL requests and transactions. To run a query, or to manipulate the database, 
the user must first build a Request File. The Request File is built by selecting "n" from the 
Subsession menu, and following the prompts for the t 3 q)e of request desired. The requests built are 
stored in the Request file specified at the beginning of the session. This file will later be run by 
returning to the Subsession menu, choosing "s" rather than "n". 




When the (r) option is picked from the ABDL interface, the Request-interface menu shown 
below will be displayed. 


Select a subsession: 

(s) SELECT: select traffic units from an existing list 
(or give new traffic units) for execution 

(n) NEW LIST: create a new list of traffic units 

(d) NEW DATABASE: choose a new database 
(p) * PERFORMANCE TESTING 

(r) * REDIRECT OUTPUT: select output for answers 

(m) * MODIFY: modify an existing list of traffic units 

(o) * OLD LIST: execute all the traffic units in an 

existing list 

(x) EXIT: return to previous menu (ABDL main menu) 

Refer to the MLDS/MBDS user manual before choosing 
subsessions marked with an asterisk (*) 

Select-> n 


We are building a new Request File, therefore, we choose "n". The following describes 
what each selection above is for. 


a. (s)-SELECT 


An option for selecting a file of previously created ABDL requests. This option 
presents a menu for displaying and submitting these requests for processing. 


b. (n)-NEW LIST 


An option for creating a new file of ABDL requests. This option presents menus 
for the creation of a file of INSERT, DELETE, UPDATE, RETRIEVE and RETRIEVE- 
COMMON requests. By following the menu, correct syntax is guaranteed. 


c. (d)-NEW DATABASE 


An option for choosing a new database to work with. This option allows the user to 
switch between different databases defined previously in the system. 


d. (r) - REDIRECT OUTPUT 


An option for specifying the output mode of the session. This option allows the user 
to direct the output to the terminal, a file, or to suppressed output. 
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e. (p) -* PERFORMANCE TESTING 

An option for enabling/disabling the internal and external performance 
measurement hooks. Do not enter this function until a thorough understanding of the system is 
gained. Refer to the note at the bottom of the menu. 

/. (m)-^ MODIFY 

An option for modifying a list of ABDL requests that have been stored in a file. 

g. (o)-* OLD LIST 

An option for executing all ABDL requests in a given file. 

h. (x)-EXIT 

Returns to the previous menu (i.e., the ABDL main menu). 

Refer to the MLDS/MBDS user manual before choosing subsessions marked with an asterisk (*) 

This statement refers to the user manual that is Appendix A of Paul Alan Bourgeois’s 17 
December 1992 thesis. 

2. Creating Requests 

We now proceed to execute each of these options in turn. We continue to use the FACSTU 
database in our examples. The following will detail how the five basic manipulations belonging 
to the KDS can be accessed and used from within the ABDL/ABDM portion of the system (i.e., 
the KDS). The five basic operations belonging to the KDS are the INSERT, RETRIEVE, 
DELETE, UPDATE, and RETRIEVE-COMMON. 

To generate a request that will manipulate the database using any one of the five basic KDS 
operations, the user must enter the file name that will contain the request interfaces. We suggest 
linking this file to the database in use by always using the database name as the name of the file. 

Enter the name for the traffic unit file 

It may be up to 40 characters long including the .ext. 

Filenames may include only one '#' character 
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as the first character before the version number. 
FILE NAME-> FACSTWI 
Enter the character for the desired Traffic Unit type. 


(r) Request 

(t) Transaction (multiple requests) 

(f) Finished entering traffic units. 

Select-> r 

a. Creating an INSERT Request 

The Insert operation takes one set of attribute-value pairs at a time and inserts the 
set as a record into the base data of the database. This operation consults the schema previously 
defined for the database and distinguishes those attribute values that are keys from those that are 
not. Keys are processed by ABDBMS against the meta data of the database to determine the cluster 
to which the record belongs and the secondary storage in which the record is to be placed. To load 
data using a batch file, use the Mass_load() function detailed in thesis Chapter V. 


Enter the character for the desired next step. 


(i) 

INSERT 

(r) 

RETRIEVE 

(u) 

UPDATE 

(d) 

DELETE 

(c) 

RETRIEVE COMMON 


Select-> i 


INSERT Request 

Begin entering keywords as you are prompted. 

You will be prompted first for the 'Attribute' and then for the 'value'. 

End each attribute or value with a single <return>. 

When you have finished entering keywords, respond to the ATTRIBUTE> prompt 
with a <return>. 



ATTRIBUTE (<cr> to fiiiish)-> TEMP 
VALUE-> Name 

ATTRIBUTE (<cr> to fmns!i)-> OID 
VALUE-> N9 

ATTRIBUTE (<cr> to finish)-> FNAME 
VALUE-> David 

ATTRIBUTE (<cr> to fiiiish)-> MI 
VALUE-> K 

ATTRIBUTE (<cr> to fmDsh)-> LNAME 
VALUE-> Hsaio 
ATTRIBUTE (<cr> to fi!ni5sh)-> 

The process will use the information above to construct an Insert Request following the 
conventions required by the system: 

[INSERT(<TEMP, Name>,<OID, N9>,<FNAME, David>,<MI, K>,<LNAME, Hsaio>)l 

Continue selecting "r" for request, then "i" for insert, inputing the information 
requested, until all of the inserts desired are complete. 

b. Creating a RETRIEVE Request 

The Retrieve operation takes two arguments; a query and a target list. The query 
specifies the set of records to be retrieved from the base data and the target list specifies the values 
to be displayed from the retrieved data. A simple target list lists the values of attribute-value pairs 
whose attribute have been targeted. A complex target list may specify an aggregate function over 
a specific attribute. An example of complex functions is taking the AVERAGE over attribute 
GRADE. The output being an average grade resulting from a manipulation of all the grades in the 


database. 



Again, start the process by selecting "r" for Request from the Request Interface 
menu. The next menu shown below allows selection of the Retrieve process. Follow the prompts 
and menus. 


Enter the character for the desired next step. 

(i) INSERT 

(r) RETRIEVE 

(u) UPDATE 

(d) DELETE 

(c) RETRIEVE COMMON 

Select-> r 


RETRIEVE Request 

Enter responses as you are prompted. You will be prompted first for 
the predicates of the query, then attributes for the target-list, 
next for an attribute for the optional BY clause and finally for 
a pointer for the optional WITH clause. 

When you have finished entering predicates for the query, respond 
to the ATTRIBUTE> prompt with a <return>. 

ATTRIBUTE (<cr> to finish)-> TEMP 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

/= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<= 

LESS THAN or EQUAL 


Select-> a 


VALUE-> Name 

So far your conjunction is 
(TEMP=Name). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > n 
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Do you wjsh to append more conjunctions to the query? (y/n) > n 

Begin entering attributes for the Target-List. When you are 

through entering attributes respond to the ATTRIBUTE> prompt with <return>. 

Do you wish to be prompted for aggregation (Y/N)? n 

ATTRIBUTE (<cr> to finish)-> OID 

ATTRIBUTE (<cr> to finish)-> FNAME 

ATTRIBUTE (<cr> to finish)-> MI 

ATTRIBUTE (<cr> to finish)-> LNAME 

ATTRIBUTE (<cr> to finish)-> 

Do you wish to use a BY clause (Y/N)? n 

At this point, the Retrieve Request has been constructed by the system using the 
answers given to the prompts provided. The request is : 

[RETRIEVE((TEMP=Name)) (OID, FNAME, MI, LNAME)] 


c. Creating an UPDATE Request 


The Update operation takes two arguments: a query and a modifier. The 
operation is carried out in four steps. 

» Step one - the records which satisfy the query are retrieved from the base data. This step 
is like the Retrieve operation. 

® Step two - each retrieved record is tagged for later removal. This step is also know as 
writing the deleting tag into a record. 

« Step three - the record with the deletion tag is placed on the secondary storage where it 
originally came from. This step is like the Insert operation. We note that no record has been 
physically removed by this operation. The removal of record deletion tags is the function of 
the garbage-collecting routine of the system which is carried out in a non-prime time 
periodically. 

® Step four - for each record to be tagged for deletion, this operation makes a copy of the 
record. The copy is changed by the modifier specified by the user. The modified copy is 
then entered into the database by the Insert operation as a new record. The old copy is marked 
for later deletion. 



Update is a process that uses the Retrieve, Delete, and Insert processes to allow 
modification of a particular record and attribute-value pair. 


Enter the character for the desired next step. 

(i) INSERT 

(r) RETRIEVE 

(u) UPDATE 

(d) DELETE 

(c) RETRIEVE COMMON 

Select-> u 


UPDATE Request 

Enter responses as you are prompted. You will be first 
asked for the predicates necessary to build the query and then 
the attribute and expression required to construct the modifier. 

When you are finished entering predicates for the query, 
respond to the ATTRIBUTE> prompt with a <return>. 


ATTRIBUTE (<cr> to fmish)-> TEMP 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

/= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<=z 

LESS THAN or EQUAL 


Select-> a 


VALUE-> Name 

So far your conjunction is 
(TEMP=Name). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > y 
ATTRIBUTE (<cr> to fmish)-> OID 
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Enter the character for the desired relational operator 


(a) 


EQUAL 

(b) 

1 — 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<= 

LESS THAN or EQUAL 


Select-> a 


VALUE-> N9 


So far your conjunction is 
(TEMP=Name)and(OID=N9). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > n 
Do you wish to append more conjunctions to the query? (y/n) > n 


Enter the attribute-being=modified. 

ATTRIBUTE (<cr> to finish)-> LNAME 

Enter the number indicating the desired modifier type 

Set attribute equal to a constant 
Set attribute equal to a function of itself 
Set attribute equal to a function of another attribute 
Set attribute equal to a function of another attribute 
of a query 

Set attribute equal to a function of another attribute 
of a pointer 

Select"> 0 


Enter Constant-> Tam 


By following the prompts and menus, the system has built the Update Request 
desired. The Update is: 

[UPDATE((TEMP= Name) and (010=^ N9)) <LNAME=Tam>] 


( 0 ) 

( 1 ) 

( 2 ) 

(3) 

(4) 
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d. Creating a DELETE Request 


The Delete operation takes only one argument, a query. In ABDBMS (the KDS), 
the Delete operation is carried out in the three steps which are the same steps as steps one through 
three of the Update operation. 


Enter the character for the desired next step. 

(i) INSERT 

(r) RETRIEVE 

(u) UPDATE 

(d) DELETE 

(c) RETRIEVE COMMON 

Select-> d 

DELETE Request 

Enter responses as you are prompted. You will be 
asked to enter attributes, values, and relational operators 
as predicates for the query. 

When you are finished entering predicates 

respond to the ATTRIBUTE> prompt with a <return>. 

ATTRIBUTE (<cr> to finish)-> TEMP 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

1= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<= 

LESS THAN or EQUAL 


Select-> a 


\ALm->Name 

So far your conjunction is 
(TEMP=Name). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > y 
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ATTRIBUTE (<cr> to finiish)-> OID 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

1= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

if) 

<= 

LESS THAN or EQUAL 


Select-> a 


VALUE-> m 

So far your conjunction is 
(TEMP=Name)and(OID=N9). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > n 
Do you wish to append more conjunctions to the query? (y/n) > n 


By following the prompts and menus, the system has built the Delete Request. The 
actual request looks like: 

[DELETE ((TEMP=Name) and (OID=N9))] 


e. Creating a RETRWE-COMMON Request 

The Retrieve-Common operation consists of two Retrieve operations with a 
Common clause. The common clause specifies an attribute of the record set determined by the 
first Retrieve operation and an attribute of the record set determined by the second Retrieve 
operation. The clause requires that output of the operation is a set of which is composed of two 
records - one from the first record set and other from the second record set such that these two 
records have common attribute values for the attributes specified in the common clause. Each 
output record can be reduced in size if a target list is used in either Retrieve operation. 

Enter the character for the desired next step. 
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(i) INSERT 

(r) RETRIEVE 

(u) UPDATE 

(d) DELETE 

(c) RETRIEVE COMMON 

Select-> c 


RETRIEVE COMMON Request 
First enter the source RETRIEVE 


RETRIEVE Request 

Enter responses as you are prompted. You will be prompted first for 
the predicates of the query, then attributes for the target-list, 
next for an attribute for the optional BY clause and finally for 
a pointer for the optional WITH clause. 

When you have finished entering predicates for the query, respond 
to the ATTRIBUTE> prompt with a <return>. 

ATTRIBUTE (<cr> to finish)-> TEMP 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

/= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<= 

LESS THAN or EQUAL 


SeIect-> a 


VALUE-> Name 

So far your conjunction is 
(TEMP=Name). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > y 


ATTRIBUTE (<cr> to finish)-> OID 
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Enter the character for the desired relational operator 


(a) 

— 

EQUAL 

(b) 

h 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

if) 

<= 

LESS THAN or EQUAL 

Select-> a 




VALUE-> m 

So far your conjunction is 
(TEMP=Name)and(OID=N4). 

Do you wish to *and' additional predicates to this conjunction? (y/n) > n 

Do you wish to append more conjunctions to the query? (y/n) > n 

Begin entering attributes for the Target-List. When you are 

through entering attributes respond to the ATTRIBUTE> prompt with <return>. 

Do you wish to be prompted for aggregation (Y/N)? n 

ATTRIBUTE (<cr> to finish)-> OID 

ATTRIBUTE (<cr> to flnish)-> FNAME 

ATTRIBUTE (<cr> to finish)-> LNAME 

ATTRIBUTE (<cr> to finish)-> 

Do you wish to use a BY clause (Y/N)? n 

COMMON ATTRIBUTE 1> OID 

COMMON ATTRIBUTE 2> O/D S 


The request being built is: 

[RETRIEVE((TEMP=Name)and(OID=N4))(OID,FNAME,LNAME)COMMON(OID,OID 

S) 

Enter the target retrieve 


RETRIEVE Request 
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Enter responses as you are prompted. You will be prompted first for 
the predicates of the query, then attributes for the target-list, 
next for an attribute for the optional BY clause and finally for 
a pointer for the optional WITH clause. 

When you have finished entering predicates for the query, respond 
to the ATTRIBUTE> prompt with a <return>. 

ATTRIBUTE (<cr> to finish)-> TEMP 

Enter the character for the desired relational operator 


(a) 

= 

EQUAL 

(b) 

/= 

NOT EQUAL 

(c) 

> 

GREATER THAN 

(d) 

>= 

GREATER THAN or EQUAL 

(e) 

< 

LESS THAN 

(f) 

<= 

LESS THAN or EQUAL 


Select-> a 


VALUE-> Course_stu 

So far your conjunction is 
(TEMP=Course_stu). 

Do you wish to 'and' additional predicates to this conjunction? (y/n) > n 
Do you wish to append more conjunctions to the query? (y/n) > n 

Begin entering attributes for the Target-List. When you are 

through entering attributes respond to the ATTRIBUTE> prompt with <return>. 

Do you wish to be prompted for aggregation (Y/N)? n 

ATTRIBUTE (<cr> to finish)-> OID 

ATTRIBUTE (<cr> to finish)-> OID S 

ATTRIBUTE (<cr> to finish)-> 

Do you wish to use a BY clause (Y/N)? n 

The request being processed is: 

[RETRIEVE((TEMP-Name)and(OID=N4))(OID,FNAME,LNAME) 
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COMMON(OID,OID_S)RETRIEVE(TEMP=Coiirse_stu)(OID,OID_S)] 


3. Running and Testing the Requests 

In the above processes, using the Request Interface from within the ABDL interface the 
user built a request file responding to prompts and menus from within the Subsession menu. In our 
example we named our Request file FACSTU#!. Building the request does not automatically 
yeild results. The request file has to be run. To mn the file, choose "r" from the ABDL interface, 
then choose "f from the Request Interface. Then select "s" from the Subsession menu to run the 
file. The menu below will appear. 


Enter TI_read_name 

Enter the name for the traffic unit file 
It may be up to 40 characters long including the .ext. 
Filenames may include only one '#' character 
as the first character before the version number. 


FILE NAME-> FACSTU#! 

After entering the file name, the contents of the file appear on screen as listed below. 


(0)[RETRIEVE(TEMP=Name)(OID,FNAME,MI,LNAME)] 

(1) [INSERT(<TEMP,Name>,<OID,N9>,<FNAME,Steven>,<MIJ>,<LNAME,greg>)] 

(2) [RETRIEVE(TEMP=Name)(OID,FNAME,MI,LNAME)] 

(3) [RETRIEVE(TEMP=Person)(OID,PNAME,PADDRESS,SEX)] 

(4) [INSERT(<TEMP,Person>,<OID,P9>,<PNAME,N9>,<P ADDRESS,A9>,<SEX,F>)] 

(5) [RETRIEVE(TEMP=Person)(OID,PNAME.PADDRESS,SEX)] 

(6) [UPDATE((TEMP=Name)and(OID=N9))<LNAME=Tam>] 

(7) [RETRIEVE(TEMP=Name)(OID,FNAME.LNAME)BY LNAME)] 

(8) [RETRIEVE(TEMP=Address)(NUMBER,STREET,CITY,ZIPCODE)] 

(9) [UPDATE((TEMP=Address)and(OID=A8))<ZIPCODE=93956>] 

(10) [RETRIEVE(TEMP=Address)(NUMBER,STREET,CITY,ZIPCODE)] 

(11) [DELETE(TEMP=Name)and(OID=N9)] 

(12) [RETRIEVE(TEMP=Name)(OID,FNAME,LNAME)] 

(13) [RETRIEVE((TEMP=Name)and(OID=N4))(OID,FNAME,LNAME) 

COMMON(OID,OID_S)RETRIEVE(TEMP=Course_stu)(OID)] 
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Select Options: 

(d) 

(n) 

(num) 

(x) 

Option-> 0 

The menu above is asking for which part of the request individually to run. The user input 
the Request Index Number "0" to run the first query. The results of the query appear on the screen 
like the listing below. 

(<OID, Nl>, <FNAME, Luis>, <MI, M>, <LNAME, Raniirez>) 

(<OID, N2>, <FNAME, Bruco, <MI, R>, <LNAME, Badgett>) 

(<OID, N3>, <FNAME, Dan>, <MI, R>, <LNAME, Kenet>) 

(<OID, N4>, <FNAME, TaeWook>, <MI, K>, <LNAME, Kwon>) 

(<OID, N5>, <FNAME, Recep>, <MI, T>, <LNAME, Tan>) 

(<OID, N6>, <FNAME, David>, <MI, K>, <LNAME, Hsiao>) 

(<OID, N7>, <FNAME, Thomas>, <MI, C>, <LNAME, Wu>) 

(<OID, N8>, <FNAME, John>, <MI, D>, <LNAME, Daley>)Exit 

Continue in this fashion to mn the requests. Use the index number to select each of the 
requests desired from the Request File. 


redisplay the traffic units in the list 
enter a new traffic unit to be executed 
execute the traffic unit at [num] 
from the above list 
exit from this SELECT subsession 
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APPENDIX B-CONTROLLER FILE CATALOG 


A. COMMUNICATIONS COMMON 

All Controller files are located on Work Station dbl 1 under; mbds/u/greg/CNTRL 


Table 3: CCOM—Communications COMMON 


File Name 

File Description 

#include 

#define 

cget-c 

Controller Get: Responsible for receipt of messages from 
the backend. 

<stdio.h> 

<sys/ 

types.h> 

<netint/ 

in.h> 

flags.def 

dblocal.def 

com- 

mdata.def 
msg.def 
' beno.def 

none 

cput.c 

Controller Put: Responsible for sending messages to the 

backend. 

<stdio.h> 

<sys/ 

types.h> 

<netint/ 

in.h> 

flags.def 

dblocal.def 

com- 

mdata.def 

msg.def 

beno.def 

none 

flags.def 

Flag Definitions: A file included in cget.c and cput.c that 
specifies which flags to define using mnemonic identifi¬ 
ers. 

none 

EnExFlag 

EnExRagg 

m_pr_flag 

pr_flag 

SRTime- 

Flag 

LangIF_Fla 

g 

make_result 

Make file specifying order of compilation and where to 
place object code. 

none 

none 















TaWe 4: COMMON 


File Name 

File Description 

#include 

#define 

tmplsr.c 

Template subroutines: A file grouping funcitons required 

<stdio.h> 

none 


to: 

flags, def 



Identify the task using this routine. 

dblocal.def 



Create database id (dbid). 

com- 



Create a record template for the database dbid 

mdata.def 



Get number of backends to set. 

beno.def 



Set number of backends. 

msg.def 



Extract userid, and dbid. 

msg.ext 
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B. INSERT INFORMATION GENERATOR 


Table 5: HG-Insert Information Generator 


File Name 

File Description 

#include 

#define 

bes.c 

Backend Selector: Called when a backend returns a clus¬ 
ter-id (or a null value). Determines a backend for record 
insertion when all backends have returned a cluster-id (or 
null value). Otherwise, it saves the cluster-id (or null 
value) returned by the backend. 

<stdio.h> 

<sys/fiie.h> 

flags.def 

beno.def 

comm- 

data.def 

iig.def 

dblocaldef 

tmpl.def 

iig.ext 

none 

didgen.c 

Database ID Generator: New Descriptor: Generates a 
new descriptor id for a type-c attribute. 

<stdio.h> 

flags.def 

comm- 

data.def 

iig.def 

dblocaldef 

tmpl.def 

iig.ext 

none 

iigx 

main(aTgc, argv) for Insertion Information Generator. 

<stdio.h> 

<sys/file.h> 

flags.def 

beno.def 

com- 

mdata.def 

iig.def 

dblocaldef 

tmpl.def 

iig.dcl 

tmpl.dcl 

none 

extern: 

msg_q[MS 

GLEN] 

msg_hdr 


93 













File Name 

File Description 

#include 

#define 

iigdbl.c 

Load a t 3 q?e-C attribute in the TCDT 

j 

<stdio.h> 

<sys/file.h> 

flags.def 

beno.def 

com- 

mdata.def 

msg.def 

iig.def 

dblocal.def 

tmpl.def 

iig.ext 

none 

iigsrx 

IGG subroutines for; 

Receiving the request_id and cluster_id. 
Receiving request_id and descriptor. 

Sending backend number selected to insert a record to the 

backends. 

Broadcasting a descriptor id to the backends. 
Sending results of the internal timing to the controller. 

<stdio.h> 

flags.def 

beno.def 

com- 

mdata.def 

msg.def 

iig.def 

dblocal.def 

none 

dblocal.def 

Buffer size speeds reading and writing CINBT (Cluster-id 
Next Backend Tables) 
struct attribute table entry, 
struct attribut table 

none 

IJ_G 

BUFFER- 

SIZE 

AT_MaxTy 

peC 

flags.def 

A file which specifies which flags to define using mne¬ 
monic identifiers. 

none 

EnExFlag 

pr_flag 

SRTime- 

Flag 

LangIF_Fla 

g 

iig.def 

Holds the cluster_id information associated with an insert 

request: 

- Builds required structures for request-id, cluster-id, 
information. 

- CINBT — Cluster Id Next Backend Table. 

- IIG-descriptor: attribute-value pair lengths 

- IIG-descriptor-descriptor-id table element. 

none 

none 


94 



























Table 5:1IG--Insert Information Generator 


File Name 

File Description 

#include 

#define 

iig.dcl 

Aggregates a collection of rid_cid_info and CINBT data. 

none 

none 

iig.ext 

Globalizes rid_cid_info, cidg_cnt, CINBT, ClNBT_file, 

AT_file. 

none 

none 

make_result 

Compiling instructions and paths. 

none 

none 

C. 

POST PROCESSING 




Table 6: PP-Post Processing 



File Name 

File Description 

#include 

#define 

pp.c 

main (argc, argv) for post processing. 

-initializes. 

-processes a message from a task in the controller includ¬ 
ing cases common to all tasks. 

-receive number of request in the transaciton from 
RPREP and put the information in the entry, adding the 
entry to the transaction information list. 

<stdio.h> 

flags.def 

beno.def 

com- 

mdata.def 

msg.def 

dblocaldef 

pp.def 

pp.dcl 

tmpl.def 

tmpl.dcl 

extern: 

msg_q 

[MSGLEN] 

msg_hdr 

ppby.c 

Creates and manipulates a hashing—the bucket table. 

<stdio.h> 

flags.def 

beno.def 

com- 

mdata.def 

pp.def 

pp.ext 

none 




























Table 6: PP-Post Processing 


File Name 

File Description 

#include 

#define 

pprba.c 

Groups aggregate_info , allocating a by-block structure to 
be used when hashing by_clause information. 

- Checks for buffer size. 

- Allocates space for new RP-by-hash. 

- Allocates an instance of PP-ResultBuffer for a request.. 

- Puts the request id, adds new entry to list, frees entry in 
PP_ResultBuffer list for a request. Puts the results for a 
request in PP_ResultBuffer and sends a completion sig¬ 
nal. 

<stdio.h> 

flags.def 

beno.def 

com- 

mdata.def 

pp.def 

pp.ext 

none 

ppsrx 

PP subroutines for; 

-returning results (sent by a backend) in the buffer, 
-returning traffic unit and error message (sent by Request 
Preparation) in the buffer. 

-returning number of requests in a transaction, 
-sending reuslts for a request to the host machine, 
-sending a traffic unit that has errors to the host, 
-sending msg to host signaling transaction finished, 
-sending results of internal timing to the controller. 

<stdio.h> 

flags.def 

dblocal.def 

beno.def 

com- 

mdata.def 

msg.def 

pp.def 

pp.ext 

tmpl.def 

none 

repmon.c 

Post Processing Reply Monitor: Monitors sending results 
to the host machine; 

-store results from a backend in a buffer. 

-when all backends have returned results send buffer info 
with a competion signal to host. 

<stdio.h> 

<ct3q)e.h> 

flags.def 

beno.def 

com- 

mdata.def 

msg.def 

pp.def 

pp.ext 


flags.def 

Defines flags needed by PP mnemonically. 

none 

EnExFlag 

EnExFlagg 

m_pr_flag 

SRTime- 

Flag 

LangIF_Fla 

g 
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Table 6: PP-Post Processing 


File Name 

File Description 

#include 

#define 

pp.def 

Defines maximums, minimums, sizes, lengths and groups 
aggregate data via “stmct”: aggregate_info, 
PP_ResultBuffer, trans_info 

none 

struct: 

aggre- 

gate_info 

PP_Result- 

Buffer 

trans_info 

NMAX 

NMIN 

MAX_AG_ 

OPS 

MAX_ATT 

R 

MXAVLN 

pp.dcl 

Declares PP structureS“PP_ResultBuffer, trans_info. 

none 

none 

pp.ext 

Globalizes structures—PP_ResultBuffer, trans_info 

none 

none 

make_result 

Compiling and resulting Paths— information. 

none 

none 

D. 

REQUEST PROCESSING 




Table 7: REQP--Request Processing 



File Name 

File Description 

#include 

#define 

chkptu.c 

Check Point Utilities: A grouping of functions. 

- Checks all the request in a traffic unit against the record 

template. 

- Checks the validity of a request. 

- Checks for proper attributes and attribute types. 

- Checks validity of non-insert requests. 

<stdio.h> 

flags.def 

beno.def 

comm- 

data.def 

reqp.def 

reqp.ext 

none 

mallocs.c 

Memory Allocation functions creating tables for: 
Aggregate definition node, aggregate index definition 
node, RC (Request Composer) request index definition 
node. Request count definition node, Request table defi¬ 
nition node. Request index definition node, update 
request information node. 

<stdio.h> 

dblocaldef 

com- 

mdata.def 

reqp.def 

none 
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Table 7: REQP--Request Processing 


File Name 

File Description 

#include 

#define 

reqcompx 

Request Composer—a grouping of functions: 

- Puts requests in the format needed by the DM (Direc¬ 

tory Manager). 

- Puts requests into the form required by the backends. 

- Puts inserts into the form required by the backends. 

- Converts a formatted request from parsed request and 

adds them to a set of formatted requests. 

- Deals with modifiers (Type III, IV). 

- Formats Retrieves. 

<stdio.h> 

flags.def 

beno.def 

comm- 

data.def 

reqp.def 

reqp.ext 

msg.def 

none 

reqp.c 

main(argc, argv): 

- Scheduling functions. 

- Processing messages from host. 

<stdio.h> 

flags.def 

beno.def 

comm- 

data.def 

reqp.def 

reqp.ext 

msg.def 

tmpl.def 

tmpl.dcl 

commsg.c 

extern: 

msg_q 

msg_hdr 

*mem_ptr 

rcomtype[2] 

no_agg[2] 

*index_req_ 

ptr 

reqpsr.c 

Request Processing Subroutines necessary for REQP: 

- Receive and buffer the nxt msg for REQP. 

- Return senders name and type of msg in the buffer. 

- Return datbase id and traffic unit. 

- Return record with changed cluster (sent by BE). 

- Broadcast a set of formmated requests to backends. 

- Notify RECP a Retreive-Common is coming. 

- Send requests to Post-Processing. 

- Send aggregate operators (in traffic unit) to PP (not 

completed). 

- Send requests with erros to PP. 

- Send a msg to all DM’s in BE’s no more generated 

Inserts. 

- Send results of internal timing to the controller. 

<stdio.h> 

dblocal.def 

flags.def 

beno.def 

com- 

mdata.def 

reqp.def 

reqp.ext 

msg.def 

tmpl.def 

none 

dblocal.def 

Defines R_E_Q_P 

none 

R_E_Q_P 
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Table 7: REQP-Request Processing 


File Name 

File Description 

#include 

#define 

flags.def 

Defines flags required by REQP processes. 

none 

EnExFlag 

EnExFlagg 

m_pr_flag 

prjflag 

SRTime- 

Flag 

LangIF_Fla 

g 

reqp.def 

Defines constants and structures needed for REQP 
- Number of request per transaction 
- area used to store information about update requests, 
-structure of request index.. 

none 

NOPred 

RC_null_ag 

g-OP 

reqp.dcl 

Declarations. 

none 

none 

reqp.ext 

Globalizes upd_req_info and SchedNo 

none 

none 

Isrc.c 

Lexicon Subroutines for reserved words and symbols 

none 

none 

ysrcx 

Parser Initiation Subroutines. 

- Establishes table pointers. 

- Establishes counters, slots, request types, aggreagate 
operators. 

- Establishes types of updates, relatioal operators, routing 

indicators. 

- Establishes tokens. 

- Transaction handling 

none 

YYDEBUG 

make_result 

Compiling and paths. 

none 

none 

flags.def (2) 

Unused flags—all are commented out. 

none 

none 
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E. 


TEST INTERFACE 


Table 8: TI-Test Interface 


File Name 

File Description 

#include 

#define 

dbl.c 

Database load: 

- Loads directory tables and/or records. 

- Loads record templates for a new database. 

- Saves database id. 

- Sends database id to other processes. 

- Gets Users id and broadcasts user id and database ids. 

<stdio.h> 

flags.def 

beno.dcl 

dblocal.def 

com- 

mdata.def 

tmpl.def 

tstint.def 

msg.def 


dblsr.c 

Database Load Subroutines: 

- Sends msg to create a database and template. 

- Sends msg to insert attribute, descriptor, and catch-all 
descriptors. 

- Generates descriptor ids. 

- Sends msg to insert type C attributes. 

- Checks status of actions taken. 

- checks the response to DEL of action. 

none 

none 

gdb.c 

Generate Database: Creates arbitrarily large test data¬ 
bases for MDBS using standard template file as input. It 
creates a standard record file as output. 

- main (argc,argv) 

j 

<stdio.h> 

com- 

mdata.def 

tstint.def 

DEBUG 

gsdesc.c 

Generate Standard Descriptor: Generates descriptor file 
for each template. 

- Includes interactive menus 
- Establishes upperAower bounds. 

Applies to the gdb.c test db generates 

<stdio.h> 

<ctype.c> 

flags.def 

com- 

mdata.def 

tstint.def 


gsgenrec.c 

Generate Standard Generic Records: Generates records 
using sets. Applies to gdb.c test db generates 

<stdio.h> 

flags.def 

com- 

mdata.def 

tstint.def 

none 
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Table 8: TI-Test Interface 


File Name 

File Description 

#include 

#define 

gsgmset.c 

Generate Standard Generate/Modify Sets: Generates and 
modifies sets of values. Applies to gbd.c test db generater. 

<stdio.h> 

<ctype.c> 

flags.def 

com- 

mdata.def 

tstint.def 

none 

gsmodset.c 

Generate Standard Modify Set: Modifies a set of values 
for an attribute by reading the set into an array for manip¬ 
ulation. Applies to gbd.c test db generater. 

<stdio.h> 

<ctype.c> 

flags.def 

com- 

mdata.def 

tstintdef 

none 

gstmpl.c 

Generate Standard Template: Generates a record template 

<stdio.h> 

<ct3^e.c> 

flags.def 

com- 

mdata.def 

tstint.def 


intest.c 

Internal Performance Tests - provides users with a way to 
monitor internal message processing routines. 

- Internal Test. 

- Initiate Timers. 

- Computes average time to process a certain msg. 

<stdio.h> 

<ctype.c> 

beno.def 

com- 

mdata.def 

tstint.def 

tstint.ext 

msg.def 


ti.c 

Test Interface Main Program: main (argc, argv) 

<stdio.h> 

flags.def 

beno.def 

msg.def 

com- 

mdata.def 

tstintdef 

tstint.dcl 

dblocal.def 

tmpl.def 

tmpl.dcl 

none 
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Table 8: TI—Test Interface 


File Name 

File Description 

#include 

#define 

tireqs.c 

Test Interface Request Subroutines: Prompts user for the 
keywords needed to assemble a request: 

- Insert 

- Retrieve 

- Delete 

- Update 

- Retrieve_common 
- Attribute names. 

<stdio.h> 

<ctype.h> 

flags.def 

com- 

mdata.def 

tstint.def 

tstint.ext 

none 

tireqsubs.c 

Subroutines necessary to build and process requests: 

- Construct queries from conjunctions 
- Build conjunctions 
- Build modifiers. 

- Get Expressions to be performed. 

- Get attribute names and values 
- Get aggregate operators. 

<stdio.h> 

<ctype.h> 

flags.def 

com- 

mdata.def 

tstint.def 

tstint.ext 

none 

tisr.c 

Test Interface Subroutines: 

- Send msg to use a database. 

- Receive the next msg for TI and store it in a buffer. 

- Handle errors 

- Request preparation and indicate completion. 

- Assign the proper db to the proper user. 

<stdio.h> 

flags.def 

dblocal.def 

com- 

mdata.def 

tstintdef 

tstint.ext 

msg.def 


tisubs.c 

' ^ 1 

Subroutines required for processing traffic units: 

- Read in name of traffic unit or response file. 

- Determine input file to be used. 

- Write traffic unit into the new traffic unit list file. 

- Read traffic unit from input file into buffer. 

- Get traffic units from user and save to TU list file. 

- Prompt for type-single request or transaction. 

- Display aU TU’s in list file. 

- Determine format of output. 

- Send TU for execution in MDBS. 

- Output or Print results/response from MDBS. 

- Handle errors in TU’s 

- Check if there are unfinished request in MDBS. 

<stdio.h> 

flags.def 

dblocal.def 

com- 

mdata.def 

tstint.def 

tstint.ext 

msg.def 

beno.def 

extern: 

msg_q[MS 

GLEN] 

msg_hdr 
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Table 8: TI-Test Interface 


File Name 

File Description 

#include 

#define 

tstint.c 

Test the Interface: 

- Test interface through continuation of session or during 
a subsession. 

- Select an output media for answers to requests. 

- Change database being used. 

- Save TU’s to a file of the user’s selection. 

- Allow modifications of old traffic units. 

- Retrieve and execute an old TU list or individual TU. 

- Print out the traffic unit sent. 

- Save new database id. 

***GSMAIN contained in get_DB(dbid) funtion. 

<stdio.h> 

<ctype.h> 

flags.def 

com- 

mdata.def 

tstintdef 

tstint.ext 

msg.def 

none 

unixtime.c 

Globalizes both stop and start timers. 

<stdio.h> 

<time.h> 

flags.def 

com- 

mdata.def 

extern: 

CRT_flg 

*resultptr 

dblocal.def 

Defines T_I 

none 

T_I 

flags.def 

Defines flags required within TI. 

none 

LangIF_Fla 

g 
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File Name 

File Description 

#include 

#define 

tstint.def 

Defines sizes, lengths, maximums, minimums, and maxi¬ 
mum number of traffic units. 

none 

i 

MNTrafUni 

ts 

RES Length 
AOLength 
SetSize 
MRLength 
MAX_REC 
ORDS 
MAXLINE 
TIMER_QS 
IZE 

TIMER_Q 

WIDTH 

TIM_STR_ 

LEN 

NO_OF_RE 

Q_REPS 

MPLength 

REQLength 

TULength 

ALLCAPS 

NOTHING 

DBCAP 

ONECAP 

NOCAPS 

FnVnS 

TLEOTU 

dbLeof 

dbl_eod 

tstint.dcl 

Test record template to be used when included in a file. 

none 

none 

ts tint, ext 

Globalizes variables and constants used in tstint.dcl 

none 

none 


F. COMMON FILES TO BOTH FRONT AND BACKENDS 


All the files common to both the front and backends are located on dbl 1 under: 
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mbds/u/greg/ 


Table 9: COMMON-Files held in common by every module. 


File Name 

File Description 

#include 

#define 

ack.c 

Acknowledgements: A collection of functions: 

- Retrieves host number from host name. 

- Initialize sockets for reliable broadcasting for Get’s. 

- Initialize sockets for reliable broadcasting for Put’s. 

- Gets acknowledgements after sending a msg of t 5 ^e 

DATAGRAM else retransmits. 

- Send a retransmission to a particular computer 

- Determins how long a broadcast msg is and returns 

number of fragments needed. 

- Slows repeated broadcast msges allowing receiveres to 

catch up. 

- Tags msgs in case retransmissions get lost too. 

- Untags received msgs since not part of MDBS process¬ 

ing. 

- Gets msgs off the net. 

- Assemble received msg fragments. 

<stdio.h> 
<sys/ 
socket.h> 
<netinet/ 
in.h> 
<netdb.h> 
<errno.h> 
<sys/ 
time.h> 
<strings.h> 
flags, def 
dblocal.def 

com- 

mdata.def 

msg.def 

beno.def 

pcl.def 

ack.dcl 

extern: 

this_host[5] 

host_names 

[MaxBack- 

ends-t-l][M 

AXPLACE 

S] 

cb.c 

Initialize communications between controller and back¬ 
ends. 

<stdio.h> 

dblocal.def 

flags.def 

com- 

mdata.def 

msg.def 

beno.def 

pcl.def 

extern: 

this_host[5] 

comiox 

Communication I/O routines: 

- Keyboard input. 

- File I/O. 

- Error handling. 

<stdio.h> 

<ctype.h> 

com- 

mdata.def 

dblocal.def 

tstintdef 


commsgx 

Handles all the common message types that are sent to 
each task. Included in the main program of each task. 

none 

none 
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Table 9: COMMON—Files held in common by every modnle. 


File Name 

File Description 

#include 

#define 

dblgeneralc. 

General database loading: Extracts and puts array data 
into the msg buffer. 

<stdio.h> 
flags, def 
com- 

mdata.def 

dblocal.def 

msg.def 

msg.ext 

none 

dbtmp- 

mod.c 

Database template modifier: 

- Creates a database node. 

- Extracts user id from request id. 

- Assigns database node to the user. 

<stdio.h> 
flags, def 
com- 

mdata.def 

dblocal.def 

tmpl.def 

tmpl.ext 

none 

error.c 

Returns error msg when based on switch number from 
this collection of user error messages. 

<stdio.h> 

com- 

mdata.def 

dblocal.def 

none 

generals.c 

General String Functions: 

- Converts a number to a string of max length of 15. 

- Converts strings to numbers and returns number value. 

- Compare strings and their values 
- Concatenate Strings. 

- Get system time in sec and microseconds. 

- Convert strings to long integer and return value. 

- Write process id to “.procname.pid” 

<stdio.h> 

<sys/ 

time.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

extern: 

- ermo 

msend.c 

Message Send 

<stdio.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

msg.def 

none 
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Table 9: COMMON-Files held in common by every module. 


File Name 

File Description 

#include 

#define 

newdb.c 

Creates an entry for a new database. 

<stdio.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

msg.def 

tmpl.def 

tmpl.ext 

none 

newtmpl.c 

Creates an entry for a new template. 

<stdio.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

msg.def 

tmpl.def 

tmpl.ext 

none 
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Table 9: COMMON—Files held in common by every module. 


File Name 

File Description 

#include 

#define 

pcl.c 

Process Controller: 

- Initialize the client putting PCL in BE and Cntrlr. 

- Initialize Backends and unique socket. 

- Set up paths to controller. 

- Put message into buffer and send it when a BE wants to 
talk to the controller. 

- Initialize the server, creating temporary sockets for 

braodcast msgs. 

- Get messages from off the Ethernet and prioritize. 

- Get first message for initialization of BE’s. 

- Set up socket address LAW host_name and port. 

- Broadcast to all other BEs. 

- Save host name.in backends. 

- Close all sockets. 

- Do DBM 

<stdio.h> 

<sys/ 

types.h> 

<sys/ 

socket.h> 

<netinet/ 

in.h> 

<arpa/ 

inet.h> 

<sy s/file. h> 
<ndbm.h> 
<ctype.h> 
<errno.h> 
<sys/ 
time.h> 
flags.def 
com- 

mdata.def 

dblocal.def 

msg.def 

beon.def 

pcl.def 

ack.def 

MAXAD- 

DRSIZE 

MAX- 

ALIASES 

select.c 

Select Database. 

<stdio.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

tmpl.def 

tmpl.ext 

none 

setbeno.c 

Set the backend number and number of backends for this 

task. 

<stdio.h> 

flags.def 

beno.def 

none 

setnobes.c 

Set the number of backends variable in task. 

<stdio.h> 

flags.def 

beno.def 

none 
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Table 9: COMMON-Files held in common by every module. 


File Name 

File Description 

#include 

#define 

sndrcv.c 

- Initiate subroutines 

- Create the connections required for inter-process com¬ 
munications. 

- Send messages from one task to another task on the 

same computer. 

- Receive next message for a task. 

- Get socket descriptor for receiver. 

- Get descriptor for next message to be read. 

- Copy header from buffer into msg header. 

- Copy header and msg into buffer. 

- Denote finish of subroutine. 

- Print process names and message types (useful in 
debugging). 

- Copy msg from buffer into message header and msg. 

- Perform diagnostics on processes. 

<stdio.h> 

<sys/ 

types.h> 

<sys/ 

socket.h> 

<netinet/ 

in.h> 

<errno.h> 

<sys/ 

time.h> 

flags.def 

com- 

mdata.def 

dblocal.def 

msg.def 

sndrcv.def 

sndrcv.dcl 

extern: 

- db_info 

*head_db_i 

nfo 

utUities.c 

A collection of necessary functions for: 

- Opening MDBS files. 

- Adding Paths. 

- Confirming database. 

- Reading templates. 

- Creating database information nodes. 

- Freeing templates from the template list. 

<stdio.h> 

flags.def 

com- 

mdata.def 

tmpl.def 

dblocal.def 


waitmsg.c 

Waits for I/O or a message. 

<stdio.h> 

<sys/ 

types.h> 

<sys/ 

time.h> 

flags.def 

com- 

mdata.def 

msg.def 

sndrcv.def 

sndrcv.ext 

none 
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Table 9: COMMON-=FiIes held in common by every module. 


File Name 

File Description 

#include 

#define 

ack.def 

Globalizes variables required for acknowledgments. 

none 

extern: 

retrans_soc 

k_get 

send_ack_s 

ock 

receive_ack 

_sock 

retrns_sock 

_send 

beno.def 

Globalizes backend numbers. 

none 

extern; 

- NoBack- 
ends 

BACKEND 

_NO 

commdata. 

def 

Common Data Definitions;- MBDS file area constants: 

! 

- Lengths that many need to be changed: 

i 

none 

DATA_AR 

EA 

HOME 

MaxPath- 

Length 

NoBElength 

MAX_AG_ 

ATTR 

MAX_RET 

R 

MAX_RTS 

MFNLength 

USE- 

RidLength 

DBIDLNT 

H 

TILength 
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Table 9: COMMON--Files held in common by every module. 


File Name 

commdata. 
def (cont’d) 


File Description #include #define 

Common Data Definitions: none RNLength 

ANLength 

AVLength 

DIL_AttrId 

DIL_DescId 

DIL_ength 

- Maximum sizes, entries, tracks, numbers.... Max- 

NoReqs 

MaxCids 

MAX_FIEL 

DS 

RT_MAX_ 

ENTRY 

REQ_MAX 

_TYPE_C 

ReqMax- 

DidSets 

QR_MAX_ 

- Timer Constants: DIDS 

RecDisk- 

Size 

no_tracks 

TrackSize 

RecSize 

MAX_ADD 

RS 

UpdCoef 

ErrDelay 

TIMER_QS 

IZE 

TIMER_Q 

WIDTH 

NO_OF_RE 

Q_REPS 

TIM_STR_ 

LEN 

ARRLEN 

NO_OF_M 

EASURE- 


MENTS 
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Table 9: COMMON-Files held in common by every module. 


File Name 


commdata. 
def (cont’d) 


File Description 


Common Data Definitions: Non-lengths 
Used to signal RECP that more addrs are coming. 


- Request types: 


- Routing indicators: 


Relational Operators: 


#include 


none 


#define 


MORADD 

R 

SPACE 

BOTrans 

EOTrans 

BORequest 

EORequest 

EOConj 

EOQuery 

EORecord 

RETRIEVE 

UPDATE 

DELETE 

INSERT 

FETCH 

RET_COM 

RET_COM 

_S 

RET_COM 

_T 

RIAPO 

RIRMR 

RIRMIDU 

RIBS 

RIRCRF 

RIRCI 

RIDIG 

ROLT 

ROLE 

ROOT 

ROGE 

ROEQ 

RONE 
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Table 9: COMMON-Files held in common by every module. 


File Name 


commdata. 
def (cont’d) 


File Description 

#include 

Common Data Definitions: - Aggregate Operators 

none 

- Modifier types in an update request: 


- End of Expression in an update. 

- Addrs found in DM going to RECP 


- Results coming from backends: 


- Index for controller, Backends: 


- End of message indicators: 



#define 


AOMAX 

AOMIN 

AOAVG 

AOSUM 

ACCOUNT 

MTO 

MTl 

MT2 

MTS 

MT4 

EOExpr 

BOAddr 

EOAddr 

BOResult 

EOResult 

CSignal 

CSInsert 

CSNonln- 

sert 

EOAttr 

CTRL 

STRING 

SMALLJN 

TEGER 

LARGEJN 

TEGER 

TRUE 

FALSE 

EOMsg 

ring_the_be 

11 

TU_end 
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Table 9: COMMON-Files held in common by every module. 
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Table 9: COMMON—Files held in common by every module. 


File Name 

File Description 

#include 

#define 

msg.def 

Message lengths and message passing id definitions: 

none 

TSPA 

LENHD 

HDLEN 

MSGIN- 

TOOFFSET 

RESTMS- 

GLEN 

MAS_HOS 

T_LEN 
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File Description 

#include 

#define 

Message lengths and message passing id definitions: 

none 

Resplength 

- Controller tasks defined: 


REQP 

IIG 

PP 

G_PCLC 

P_PCLC 

- Host task defined: 


TI 

- Backend tasks defined: 


DM 

RECP 

CC 

G_PCLB 

P_PCLB 

DIO 

- Message types defined: 


Host- 

TrafUnit 

CH_ReqRes 

ChH_Trans 

Done 

Get Tmpl 

- Msg types for msgs from Req-Prep to Post-Proc: 


ReturnTmpl 

errReturnT- 

mpl 

- Msg types for msgs from ReqPrep to DM 


NoOfReqs- 

- Msg types for msgs from ReqPrep to RECP 


InTrans 

- Msg types for msgs from IIG to DM 


AggOps 

ReqsWith- 

- Msg types for msgs from DM to IIG 


Err 

ParsedTraf 

- Msg types for msgs from RECP to PP 


Unit 

RetComNo- 

tification 

NewDesc 

BeNo 

ClusId 

Req- 

ForNewD- 

escld 

BC_Res 

BC_AO_Re 

s 
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Table 9: COMMON—Files held in common by every module. 


File Name 

msg.def 

(cont’d) 


File Description 

#include 

- Msg t 5 q)es for msgs from RECP to REQP: 

none 

- Msg types for msgs from DM in one backend to DM’s 

in others: 

- Msg types for msgs from DM to RECP: 


- Msg types for msgs from RECP to DM: 


- Msg types for disk I/O signals RECP to RECP 


- Msg types for msgs from DM to Concur-Ctrl(BE) 


- Msg types for msgs from Concur-Ctrl to DM 


- Msg types for msgs from RECP to Concur-Ctrl 


- Msg types to All Tasks 


117 



#define 



Clus 

RetFet- 

Caused- 

ByUpdRes 

SpaceLeft 

reqDiskAd- 

drs 

Changed- 

ClusRes 

Updins 

Fetch 

Old- 

NewValues 

SrceFin- 

ished 

PIO_READ 

PIO_WRIT 

E 

OLD_REQ 

TypeC_attrs 

TrafUnit 

DidSet- 

sTrafUnit 

CidsFor- 

TrafUnit 

AttrRe- 

alease 

InsAllAt- 

trsRelease 

DidSetsRe- 

lease 

AttrLocked 

Did- 

SetsLocked 

CidsLocked 

Rid- 

OffiniReq 

NoMoreGe- 

nlns 

UpdFin- 

ished 

Bucketinfo 

BC_BY_R 

ES 










Table 9: COMMON-Files held in common by every module. 


File Name 


msg.def 

(cont’d) 


File Description 


- Massage types to ALL tasks: 


- Error Messages: 


Messages for timing Request Preparation (REQP) 


#include 


none 


#define 


CatchaU 

LoadtypeC 

Error 

ErrorFree 

NewDB 

Template 

SetNoBEs 

BEwho 

Createerr 

Inserterr 

Lookuperr 

Finderr 

Descerr 

Cathcerr 

Updateerr 

LoadCerr 

errNewDB 

errTemplate 

SelectData- 

base 

errSelect- 

Database 

TReqNo- 

tOKM 

TReqOKlR 

eqM 

TReqOK- 

AggM 

TReq- 

CompM 

TReqBroad 

M 


TReqSyn- 

ErrM 

TReqCh- 

CIM 

TReqN- 

MGIM 

TReqAllM 
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Table 9: COMMON--FiIes held in common by every module. 


File Name 

File Description 

#include 

#define 

msg.def 

(cont’d) 

- Messages for timing Insert Info Gen (IIG): 

- Messages for timing Post Processing (PP): 

- Messages for timing Directory Mgmt (DM): 

- Messages for timing Concurrency Control (CC): 

119 

none 

TldTyCM 

TClIdm 

TReqFNe- 

DeldM 

TIIGAllM 

TReqW- 

ErrM 

TNoORIT 

M 

TAggOpsM 

TBCResM 

TBCA- 

oResM 

TPPAllM 

TDM_PTU 

M 

TDM_NM 

GEM 

TDM_BNM 

TDM_ND 

M 

TDM_DIM 

TDM_DCM 

TDM_DA_I 

M 

TDM_DD_ 

AM 

TDM_DCA 

M 

TDM_ALM 

TDM_L_D 

SM 

TDM_C_L 

M 

TDM_ONV 

M 

TDM_UFM 

TDM_A11M 

TCi- 

FoTrUnM 

TTyCAt- 

Tum 

TDiS- 

eTrUnM 

TAtRelM 

TlnAlA- 

tReM 










Table 9: COMMON-Files held in common by every module. 


File Name 

File Description 

#include 

#define 

msg.def 

(cont’d) 

- Messages for timing Concurrency Control (CC); 

- Messages for timing Record Processing (RECP) 

- Messages to get the time from any process: 

none 

TDiSeRem 

TUpFinM 

TRecpCpM 

TCCAllM 

TReqDis- 

AddrM 

TChCl- 

ResM 

TnoMoGe- 

InM 

TFetchM 

ToOl- 

dReqM 

TPio- 

WriteM 

TPioReadM 

TRecpAUM 

TDisklOM 

GeTimes 

Tim_Arr_E 

mp 

Stop 

pcl.def 

Process Control definitions for ethernet: 

- Internet Port numbers: 

none 

MaxBack- 

ends 

charMax- 

Backends 

CNTRL_N 

AME 

OFFSET 

NETNAME 

BE_PORT 

CNTRL_P 

ORT 

MAX- 

PLACES 

MAXISI 

BRDCSTS 

Z 
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Table 9: COMMON--Files held in common by every module. 


File Name 

File Description 

#include 

#define 

sndrcv.def 

Socket Definitions for communications. 

<sys/un.h> 

<ermo.H> 

PREFIX 

NoCntrl- 

Proc 

NoBeProc 

tmpl.def 

Template Definitions for database information tables. 

none 

none 

ack.def 

Definitions for acknowledgements. 

none 

RETPORT 

ACKPORT 

MAXINT 

DELIM- 

CHAR 

ISIPREFIX 

NOFRAGS 

host_name_ 

len 

min_ws_nu 

mber 

max_ws_nu 

mber 

beno.dcl 

Backend Number Declarations. 

none 

none 

msg.dcl 

Message Declarations. 

none 

none 

sndrcv.dcl 

Globalizes and declares variables for socket connections: 
Initiating, sending, and receiving. 

none 

none 

tmpl.dcl 

Associates users to databases. 

none 

none 

msg.ext 

Globalizes variables msg_q and msg_hdr. 

none 

none 

sndrcv.ext 

Variables global to intsr, send, and receive. 

none 

none 

tmpl.ext 

Associates database id’s with databases. 

none 

none 
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APPENDIX C-MASS LOAD() FUNCTION SOURCE CODE 


#include <stdio.h> 
ttinclude <strings.h> 

#include <ctYpe.h> 
ttinclude <licoinmdata .h> 

#include <ool.h> 

#include <ool_lildcl.h> 

#include <ool_kc.h> 

#include "flags.def" 

o_mass_load(record_file) 
char *record_file; 

/* This function is used to load a group of records from a 
record file. The syntax is the same as that of an ABDL 
record file. Calls procedure make_insert(--) for each 
obj ect. 

*/ 

/* An important note is either all the inserts are 
accomplished or none are done. This is due to the use of a 
transaction file, which will 

not execute the requests until there are no errors in the 
file. */ 

{ 

char 

db_name [DBNLength + 1], 

cls_name [RNLength + 1], input_line [80], 

request [1024], supcls_array [10][RNLength + 

1 ] , 

*add_path(); 


struct 

ocls_node 


*cls_ptr; 

struct 

obj_dbid_node *db_ptr; 

int 

i. 


continu = TRUE, 

*error = FALSE, 

more_objects, not_found; 

char 

key[ANLength + 1]; 
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FILE *record_fd, *trans_fd; 

#ifdef EnExFlag 

printf("Enter o_mass_load\n"); 
fflush(stdout); 
tendif 

/* ool_ptr and okc_ptr are initialized here for the KC 
routine, */ 

/* 

ool_chk_responses_left. 

*/ 

ool_ptr = &(cuser_obj_ptr->ui_li_type.li_ool); 
okc_ptr = &(ool_ptr->oi_kc_data.kci_o_kc); 

if {! (record_fd = fopen(record_file, "r"))) 

printf("\n\nERROR -- the file, %s, does not exist.\n", 
record_file); 
else 
{ 

trans_fd = fopen{".TransFile", "w" ); /* open 

transaction file */ 

db_ptr = ool_info_ptr->oi_curr_db.cdi_db.dn_obj; 
/*check database name */ 

fscanf(record_fd, "%s \n", db_name); 
to_caps(db_name); 

if (strcmp (db_name, db_ptr->odn_name)) 

{ 

printf("\n\nERROR -- %s is the currently opened 
database. This is not", db_ptr->odn_name); 

printf("\n a mass insert file for that 

database."); 

*error = TRUE; 

} 

else /* correct database name */ 

{ 

cls_ptr = db_ptr->odn_first_cls; 
fscanf(record_fd, "%s \n", input_line); 
if (strcmp(input_line, "@")) 

{ 

*error = TRUE; 

printf("ERROR--missing '@); 

} 
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/*get all the classes in this loop*/ 
else 
{ 

continu = TRUE; 
do 
{ 

not_found = TRUE; 

if (f scanf (record_fd, "\n %s \n", cls_naine) ) 

/* check for correct */ 

{ 

while (cls_ptr && not_found) 

if (! strcmp (cls_naitie, cls_ptr->ocn_name) ) 

not_found = FALSE; 

else 

cls_ptr = cls_ptr->ocn_next_cls; 

} 

if (not_found) 

{ 

printf("\n\nERROR %s is not a class name", 

cls_name); 

*error = TRUE; 

} 

/*if correct class name, insert in request and call 
make_insert*/ 
else 
{ 

more_objects = TRUE; 
while(more_obj ects) 

{ 

/*reset array to 0; array keeps track of super 
classes visited to avoid naming same class 
twice if there is a cycle*/ 
for (i = 0; i < 10; i++) 

supcls_array[i][0] = '\0'; 

if (fscanf(record_fd, "%s \n", key)) 
if (!strcmp(key, "@")) 

more_objects = FALSE; 
else if (!strcmp(key, "$“)) 

{ 

more_objects = FALSE; 
continu = FALSE; 

} 

else 
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{ 

make_insert(cls_ptr, request, record_fd, trans_fd, 
&error, supcls_array, key); 

} 

/*end if @11$ */ 
else 
{ 

* error = TRUE; 

printf{"ERROR--missing '@‘ or 

} 

}/*end while more_objects*/ 
cls_ptr = db_ptr->odn_first_cls; 

}/*end if correct class name*/ 

} 

while(continu && !error); /*end do loop*/ 

} /*end if '@'*/ 

} /*end if odn name is 

okay*/ 

if (!error && strcmp(key, "$")) 

{ 

printf{“\nERROR — \"$\" missing.\n"); 

★error = TRUE; 

} 

fclose(record_fd); 
fclose(trans_fd); 


/*if no errors, insert the records in the database*/ 
if(!error) /* insert the records */ 

{ 

trans_fd = fopen(".TransFile" , "r"); 

while (fscanf(trans_fd, "%[^\n]", request) && 
strcmp(request,"\n")) 

{ 

printf("%s\n",request); 

TI_S$TrafUnit(db_ptr->odn_name, request); 
ool_chk_responses_left(FALSE); 

TI_finish(); 

fscanf(trans_fd, "%[\n]",request); 

} 

fclose(trans_fd); 
system("rm .TransFile"); 

}/* end "if !error, insert records"*/ 
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}/*end if record open*/ 


#ifdef EnExFlag 

printf("Exit o_mass_load\n"); 
fflush(stdout); 

#endif 

} /* end o_mass_load */ 

/* called by o_inass_load. Builds ABDL inserts, traversing 
inheritance tree. If a class is a sub class, builds 
separate INSERTS for each of its super classes, using the 
OBJ_ID value from the root of this branch of the 
inheritance hierarchy for each class INSERT.*/ 

make_insert(cls_ptr, request, record_fd, trans_fd, error, 
supcls_array, key) 


struct 

ocls_node *cls_ptr; 


char 

request [1024], 
supcls_array [10] [RNLength + 
key[ANLength + 1]; 

1] , 

int 

*error; 


FILE 

*record_fd, *trans_fd; 


{ 

struct 

oattr_node *attr_ptr; 


struct 

o_supcls_node *supcls_ptr; 


char 

attr[ANLength 

+ 1] / 


cl[RNLength + 

1] , 


input_line [80] ; 


int 

cont = TRUE, 



num_attr, 
no_cycle, 
i; 


cont = TRUE; 

/*if this is a subclass, 
supclasses*/ 

if {cls_ptr->ocn_supcls 

{ 


climb hierarchy and build 

Following part of the code is never placed 


I 


o: 


into the running system code. The code 
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supcls_ptr = cls_ptr->ocn_first_supcls; 
i = 0; 

while(supcls_ptr) 

{ 

no_cycle = TRUE; 

while ((supcls_array[i][0] != '\0') && no_cycle) 

/*check to see if there is a cycle with this supclass*/ 

{ 

if (!strcmp(supcls_ptr->osn_name, 
supcls_array[i])) 

no_cycle = FALSE; 

i++; 

} 

if (no_cycle) 

{ 

strcpy(supcls_array[i], supcls_ptr->osn_name); 
inake_insert (supcls_ptr->osn_supcls, request, 
record_fd, trans_fd, &error, supcls_array, key); 

} 

supcls ptr = supcls_ptr->osn_next_supcls; 

} /*end while supcls*/ 

} /*end if els Dtr->ocn supcls*/ 

/*build the ABDL insert*/ 
attr_ptr = cls_ptr->ocn_first_attr; 

num_attr = cls__ptr->ocn_nuin._attr; /* initialize attr 
count */ 

/*put class name and OBJECTID in INSERT*/ 
strcpy(request, "[INSERT (<TEMP, "); 

/*change class name to first letter caps, rest lower case 
to conform 

to ABDL*/ 

strcpy(cl, cls_ptr->ocn_name); 

if{(cls_ptr->ocn_name[0] >= 'a') && (cls_ptr->ocn_name[0] 
<= ■z ' ) ) 

cl[0] = toupper(cls_ptr->ocn_name[0]); 
for(i =1; i < strlen(cls_ptr->ocn_name); ++i) 

if((cls_ptr->ocn_name[i] >= 'A')&&(cls_ptr->ocn_name[i] 
<= 'Z')) 

cl[i] = tolower(cls_ptr->ocn_name[i]); 

/*end change case block*/ 
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strcat(request, cl); 
strcat(request, ">, <"); 
strcat(request, "OBJECTID"); 
strcat(request, ", "); 

strcat(request, key); 

if ( ! strcmp (attr_ptr->oan_naine, "OBJECTID")) 

{ 

attr_ptr = attr_ptr->oan_next_attr; 

-- nuin_attr; /* initialize attr count */ 

} 

/*put non-key values in INSERT*/ 
while (cont && nuin_attr) 

{ 

if (f scanf (record_f d, "%["' \t\n]", input_line) != 1) 
cont = FALSE; 

else if (! strcmp ( input_line, "®") M 
! strcmp(input_line, "$")) 

{ 

printf("ERROR -- or '$' out of sequence."); 

*error = TRUE; 
cont = FALSE; 

} 

else 

{ 

strcat(request, ">, <"); 

strcat(request, attr_ptr->oan_name); 

strcat(request, ", "); 

/* fix up attr value into ABDL form and append into 
INSERT */ 

if (input_line[0] >= 'a' && input_line[0] <= 'z') 
input_line[0] = toupper(input_line[0]); 
for (i =1; i < strlen(input_line); ++i) 

if (input_line[i] >= 'A' && input_line[i] <= 'Z') 
input_line[i] = tolower(input_line[i]); 
strcat(request, input_line); 

-- num_attr; 

attr_ptr = attr_ptr->oan_next_attr; 
fscanf(record_fd, "%[ \t]", input_line); 
fscanf(record_fd, "%[ \n]", input_line); 

}/*end if input_line*/ 

}/*end while cont and attr*/ 
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if (cont) 

{ 

streat(request, ">)]"); 

fprintf (trans_fd, "%s\n'' 

} 

}/*end inake_insert*/ 


request) ; 
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APPENDIX D-KFS SOURCE CODE 


#include, <stdio.h> 

#include <licomindata .h> 
#include <ool.h> 

#include "flags.def" 

o_kernel_forinatting_systein() 
{ 


int 

i = 0, 
j = 0, 

NumCol = 0; 


int 

OddMark = TRUE; 


int 

FirstAttribute 

= TRUE; 

int 

FirstAttributeSet = TRUE 

char 

^response; 


char 

temp[InputCoIs 

+ 1]; 

struct 

tempos tr_info 

*value. 


*teinp_str_info_alloc () ; 

#ifdef EnExFlag 

printf ("Enter o_kernel_forinatting_systein\n") ; 

#endif 

response = ool_ptr~>oi_kfs_data.kfsi_obj.koi_response; 

++response; skip '[’ character in response */ 

while (*response 1= CSignal) /* CSignal is '?• */ 

{ 

temp[i] = *response; 

++i; 

if (^response == EMARK) /* EMARK is *\0' ! 

{ 

i = 0; 

if (OddMark) /* end of attribute name */ 

{ 

if (FirstAttributeSet) 

{ 

if (FirstAttribute) 

{ 

strcpy (ool_ptr->oi_kfs_data .kf si_obj . koi_f irst_attr 

temp) ; 

FirstAttribute = FALSE; 
if (strcmp(temp, "COMMON")) 

{ 

write_attr(temp); 

/* print first attr as heading */ 

++NumCol; 
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temp) ) 


} 

else 

{ 

if (strcmp (ool_ptr->oi_kf s_data . kf si_obj . koi_f irst_attr, 


{ 

write_attr(temp); 

/* print next attr as heading */ 

-H+NumCol; 

) 

else 

{ /* heading attributes are already completed */ 
printf("\n"); 

FirstAttributeSet = FALSE; 


for (j = 0; (j < (NumCol * ANLength + NumCol)); j++) 
printf("-"); 
printf("Xn"); 

/* print first line of values already stored */ 
while (ool_ptr~ 

>oi__kf s_data. kf si_obj . koi_attr_values) 

{ 

value = ool_p>tr- 

>oi_kf s_data .kf si_obj .koi_attr_values ; 

write_attr(value->tsi_str); 

ool_ptr->oi_kfs_data.kfsi_obj .koi_attrevalues = 

value- 


>tsi_next; 


/* end else, i.e. 


} 

printf (*' \n") ; 

} 

heading attributes already completed */ 


} /* end not FirstAttribute */ 


} /* end if FirstAttributeSet */ 


else /* not FirstAttributeSet */ 

{ 

if (istrcmp(temp, 

ool^ptr- 

>oi_kfs_data.kfsi_obj .koi_first__attr) ) 
printf("\n“); 

/* we are back to the first attr name */ 

} 


) /* end if OddMark */ 

else /* not OddMark, i.e. end of attribute value */ 

{ 

if (FirstAttributeSet) 
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/* don't print value, but store it */ 

{ 

if (strcmp(temp, "File")) 

{ 

if ( I ool__ptr- 

>oi_kfs_data.kfsi_obj .koi_attrevalues) 

{ 

value = teinp_str_info_alloc(); 
ool_ptr- 

>oi__kf s__data .kfsi_obj .koi_attr_values =value; 

) 

else 

{ 

value->tsi_next = temp_str_info_alloc () ; 
value = value->ts i_next; 

} 

strcpy(value->tsi_str, temp); 

} 

if {*(response +1) == CSignal) 

{ 

printf("\n"); 

for (j = 0; (j < (NumCol * ANLength + NumCol)); 

j++) 

printf; 
printf("\n”); 


/* print first line of values already stored */ 
while (ool_ptr” 

>oi_kfs_data.kfsi_obj .koi_attrevalues) 

{ 


value = ool__ptr~ 

>oi_kf s_data. kf si_obj . koi_attrevalues ; 

write_attr(value->tsi_str); 

ool_ptr->oi_kf s_data. kf si_obj . koi_attr_values 

value- 


>tsi_next; 

} 

} 

} 

else /* not FirstAttributeSet's value */ 

{ 

if (strcmp(temp, "File")) 
write_attr(temp); 

} 


} /* end else not OddMark */ 

OddMark = IOddMark; 

} /* end if (^response == EMARK) */ 
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++response; 


} /* end while (^response 1= CSignal) */ 

printf("\n“); /* for the last line of results */ 

/* free up kfs attr values list */ 

while (ool__ptr->oi_kfs_data.kfsi_obj.koi_attr_values) 

{ 

value = ool_ptr~>oi_kfs_data.kfsi_obj .koi_attr_values; 
ool_ptr->oi_kfs_data.kfsi_obj .koi_attr_values = value->tsi_next; 
free(value); 

) 

#ifdef EnExFlag 

printf ("Exit o_kernel_formatting_systein\n") ; 

#endif 

} /* end o_kernel_formatting_system */ 


write__attr (temp) 
char temp[]; 

{ 

while (strlen(temp) < ANLength) 
strcat(temp, " "); 
streat(temp, "}"); 
printf("%s", temp); 

) 
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